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currency  among  activities  Ceui  be  permitted.  In  addition,  by  en¬ 
capsulating  the  synchronization  and  recovery  needed  to  support 
atomicity  in  the  implementations  of  the  shared  objects,  modula¬ 
rity  can  be  enhanced. 

kThis  dissertation  addresses  three  fundamental  questions: 

What  is  an  atomic  type? 

How  can  an  atomic  type  be  specified? 

How  can  an  atomic  type  be  implemented? 

Atomicity  of  activities  is  a  global  property  of  an  entire  system, 
while  atomicity  of  types  is  a  local  property  of  individual  types. 
This  dissertation  examines  three  definitions  of  atomicity  for 
types,  each  of  which  is  optimal:  No  strictly  weaker  definition 
of  (local)  atomicity  for  types  suffices  to  ensure  (global) 
atomicity  of  activities.  .The  definitions  of  atomicity  discussed 
encompass  both  serializability  and  recoverability,  and  use  user- 
supplied  specifications  of  objects  to  permit  greater  concurrency. 

The  specification  framework  presented  in  t^s  dissertation 
divides  "the  specification  of  a  data  typJy^^n^o  two  parts:  the 
serial  specification,  which  describes  how  the  type  behaves  in 
the  absence  of  concurrency  and  failures,  and  the  behavioral  spe¬ 
cification,  which  describes  how  the  type  supports  atomicity.- 
This  division  permits  the  programmer  of  an  individual  activity  to 
ignore  how  atomicity  is  achieved,  and  to  focus  on  the  serial  be¬ 
havior  of  each  object.  In  addition,  the  definitions  of  atomicity 
permit  the  behavioral  specification  of  a  type  to  be  derived 
systematically  from  its  serial  specification. 

A  novel  two-phase  locking  protocol,  covering  both  synchronization 
and  recovery,  is  presented  and  verified.  The  protocol  uses  in¬ 
formation  about  the  behavior  of  objects  to  achieve  greater  con¬ 
currency  than  can  be  achieved  with  protocols  based  on  read  and 
write  operations.  In  addition,  the  protocol  permits  the  results 
of  an  operation,  as  well  as  its  arguments,  to  be  used  in  deter¬ 
mining  the  appropriate  lock  mode  for  the  operation.  Furthermore, 
the  protocol  permits  operations  to  be  both  partial  and  non- 
deterministic. 

Finally, ^several  implementations  of  atomic  types  are  presented 
illustrating  how  existing  techniques  for  synchronization  and  re¬ 
covery  can  be  extended  to  use  information  about  the  behavior  of 
objects  to  increase  concurrency The  dissertation  also  explores 
linguistic  support  for  atomic  types,  analyzing  the  advantages  and 
disadvantages  of  alternative  approaches. 


MCUNITV  CkAMmCATION  9W  TNM  Oatm 


Specification  and  Implementation 

of 

Atomic  Data  Types 


by 

William  Edward  Weihl 

S.M..  Massachusetts  Institute  of  Technology  (1980) 

Submitted  in  partial  fulfillment 
of  the  requirements  for  the 
-jdeqree  of 

Doctor  of  Philosophy 

at  the 

Massachusetts  Institute  of  Technology 
March  1984 

©  Massachusetts  Institute  of  Technology  1984 


Acce: 

NTIS 

DTIC 

Unann 

Justl 

islon  For 

graai  Jg 

TAB  ^ 

ounoed  [] 

fication  1 

_ _ _ 

1 

By 

Distribution/ 

Availability  Codes 

Diet 

Avail 

Spec 

and/or 

lax 

Signature  of  Author 


Department  of  Electrical  Engineering  and  Computer  Science 

March  7, 1984 


Certified  by. 


Barbara  H.  Liskov 
Thesis  Supervisor 


Accepted  by. 


Arthur  C.  Smith 
Chairman,  Departmental  Committee 


I 


3 


Specification  and  Implementation 
of 

Atomic  Data  Types 


by 

William  Edward  Weihl 

Submitted  to  the  Department  of  Electrical  Engineering  and  Computer  Science 
on  Mar'.h  7, 1984  in  partial  fulfillment  of  the  requirements 
for  the  Degree  of  Doctor  of  Philosophy 

Abstract 

Maintaining  the  consistency  of  long-lived,  on-line  data  is  a  difficult  task,  particularly  in  a 
distributed  system.  This  dissertation  focuses  on  atomicity  as  a  fundamental  organizational 
concept  for  such  systems.  It  explores  an  approach  in  which  atomicity  is  ensured  by  the  data 
objects  shared  by  concurrent  activities:  such  objects  are  called  atomic  ob/ects,  and  data 
types  whose  objects  are  atomic  are  called  atomic  types.  By  using  information  about  the 
behavior  of  the  shared  objects,  greater  concurrency  among  activities  can  be  permitted.  In 
addition,  by  encapsulating  the  synchronization  and  recovery  needed  to  support  atomicity  in 
the  implementations  of  the  shared  objects,  modularity  can  be  enhanced. 

This  dissertation  addresses  three  fundamental  questions: 

What  is  an  atomic  type? 

How  can  an  atomic  type  be  specified? 

How  can  an  atomic  type  be  implemented? 

Atomicity  of  activities  is  a  global  property  of  an  entire  system,  while  atomicity  of  types  is  a 
local  property  of  individual  types.  This  dissertation  examines  three  definitions  of  atomicity  for 
types,  each  of  which  is  optimal:  No  strictly  weaker  definition  of  (local)  atomicity  for  types 
suffices  to  ensure  (global)  atomicity  of  activities.  The  definitions  of  atomicity  discussed 
encompass  both  serializability  and  recoverability,  and  use  user-supplied  specifications  of 
objects  to  permit  greater  concurrency. 

The  specification  framework  presented  in  this  dissertation  divides  the  specification  of  a  data 
type  into  two  parts:  the  serial  specification,  which  describes  how  the  type  behaves  in  the 
absence  of  concurrency  and  failures,  and  the  behavioral  specification,  which  describes  how 
the  type  supports  atomicity.  This  division  permits  the  programmer  of  an  individual  activity  to 
ignore  how  atomicity  is  achieved,  and  to  focus  on  the  serial  behavior  of  each  object.  In 
addition,  the  definitions  of  atomicity  permit  the  behavioral  specification  of  a  type  to  be  derived 
systematically  from  its  serial  specification. 


A  novel  two  phase  locking  protocol,  covering  both  synchronization  and  recovery,  is 
presented  and  verified.  The  protocol  uses  information  about  the  behavior  of  objects  to 
achieve  greater  concurrency  than  can  be  achieved  with  protocols  based  on  read  and  write 
operations.  In  addition,  the  protocol  permits  the  results  of  an  operation,  as  well  as  its 
arguments,  to  be  used  in  determining  the  appropriate  lock  mode  for  the  operation. 
Furthermore  the  protocol  permits  operations  to  be  both  partial  and  non  deterministic. 

Finally,  several  implementations  of  atomic  types  are  presented,  illustrating  how  existing 
techniques  for  synchronization  and  recovery  can  be  extended  to  use  information  about  the 
behavior  of  objects  to  increase  concurrency  The  dissertation  also  explores  linguistic  support 
for  atomic  types,  analyzing  the  advantages  and  disadvantages  of  alternative  approaches. 
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Chapter  One 
Introduction 


There  are  many  applications  in  which  the  manipulation  and  preservation  of  long-lived,  on  line 
data  is  of  primary  importance  Examples  of  such  applications  are  banking  systems,  airline 
reservation  systems,  office  automation  systems,  database  systems,  and  various  components 
of  operating  systems.  A  major  issue  in  such  systems  is  preserving  the  consistency  of  on  line 
data  in  the  presence  of  concurrency  and  hardware  failures  In  this  dissertation  we  consider 
how  to  define  data  objects  that  help  provide  this  consistency. 

To  support  consistency  it  is  helpful  to  make  the  activities  that  use  and  manipulate  data 
atomic.  Atomic  activities  are  often  referred  to  as  actions  or  transactions:  they  were  first 
identified  in  work  on  databases  [Davies  73.  Davies  78.  Eswaren  et  al.  76]  Atomic  activities  are 
characterized  informally  by  two  properties:  serializability  and  recoverability.  Senaiizabihly 
means  that  the  concurrent  execution  of  a  group  of  activities  is  equivalent  to  some  serial 
execution  of  the  same  activities.  Recoverability  means  that  ^ach  activity  appears  to  be  all-or- 
nothing:  either  it  executes  successfully  to  completion  (in  which  case  we  say  that  it  commits). 
or  it  has  no  effect  on  data  shared  with  other  activities  (in  which  case  we  say  that  it  aborts). 

Nested  transactions  [Davies  73,  Reed  78,  Moss  81.  Lynch  83]  are  useful  for  decomposing 
activities  into  smaller  units.  Nested  transactions  provide  increased  failure  tolerance 
Subtransactions  of  a  transaction  (ail  independently  of  each  other  and  independently  of  the 
containing  transaction.  In  addition,  nested  transactions  can  be  used  to  run  parts  of  the  same 
activity  concurrently,  while  ensuring  that  their  concurrent  execution  is  serializable.  As 
discussed  in  (Liskov  82],  nested  transactions  permit  a  simple  implementation  of  a  remote 
procedure  call  primitive  with  "at-most-once"  semantics:  A  remote  call  is  executed  either  zero 
or  one  times;  partial  and  multiple  executions  cannot  occur. 

Atomicity  simplifies  the  problem  of  maintaining  consistency  by  decreasing  the  number  of 
cases  that  need  to  be  considered.  Since  aborted  activities  have  no  effect,  and  every 
concurrent  execution  is  equivalent  to  some  serial  execution,  consistency  is  ensured  as  long 
as  every  possible  serial  execution  of  committed  activities  maintains  consistency.  Even  though 
activities  execute  concurrently,  concurrency  can  be  ignored  when  checking  for  consistency. 

In  this  dissertation  we  explore  an  approach  in  which  atomicity  is  achieved  through  the  shared 
data  objects,  which  must  be  implemented  in  such  a  way  that  the  activities  using  it  appear  to 
be  atomic.  Objects  that  provide  appropriate  synchronization  and  recovery  are  called  atomic 
objects:  atomicity  is  guaranteed  only  when  all  objects  shared  by  activities  are  atomic  objects 
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By  encapsulating  the  synchronization  and  recovery  needed  to  support  atomicity  in  the 
implementations  of  the  shared  objects,  we  can  enhance  modularity,  m  addition,  by  using 
information  about  the  specifications  of  the  shared  objects,  we  can  increase  concurrency 
among  activities. 

Atomic  objects  are  encapsulated  within  atomic  abstract  data  types.  An  abstract  data  type 
consists  of  a  set  of  objects  and  a  set  of  primitive  operations:  the  primitive  operations  are  the 
only  means  of  accessing  and  manipulating  the  objects  [Liskov  &  Zilles  74],  In  addition,  the 
operations  of  an  atomic  type  ensure  senalizability  and  recoverability  of  activities  using  the 
type. 

In  this  dissertation  we  investigate  the  semantics  of  atomic  types  and  the  problems  involved  in 
implementing  them.  We  address  three  fundamental  questions: 

What  Is  an  atomic  type'> 

We  need  a  precise  characterization  of  the  behavior  of  atomic  objects.  For 
example,  we  need  to  know  how  much  concurrency  can  be  allowed  by  an 
atomic  type. 

How  do  we  specify  an  atomic  type? 

What  aspects  of  the  type’s  behavior  must  appear  in  the  specification  of  an 
atomic  type,  and  how  should  the  specification  be  structured? 

How  do  we  Implement  an  atomic  type? 

What  problems  must  be  solved  in  implementing  an  atomic  type,  and  what 
kinds  of  programming  language  constructs  make  this  task  simpler? 

The  remainder  of  this  chapter  is  organized  as  follows:  In  Section  1.1,  we  review  protocols  for 
implementing  atomicity  Next,  in  Section  1.2,  we  discuss  atomic  types  in  more  detail.  Then,  in 
Section  1.3,  we  summarize  the  contributions  of  this  dissertation.  In  Section  1.4,  we  discuss 
related  work.  Finally,  in  Section  1  5,  we  outline  the  rest  of  the  dissertation. 


1.1  Implementing  Atomicity 

There  are  two  subproblems  that  must  be  solved  to  implement  atomicity:  recovery  of  aborted 
activities,  and  scheduling,  or  synchronization,  of  concurrent  activities.  The  effects  of  aborted 
activities  must  be  undone,  and  the  earlier  states  of  objects  recovered,  to  ensure  that  aborted 
activities  have  no  effect  on  the  state  of  the  system.  In  addition,  activities  must  be 
synchronized  to  avoid  non  serializable  executions.  We  discuss  these  two  subproblems  in  the 
next  two  subsections. 
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1.1.1  Recovery 

Recovery  is  accomplished  by  maintaining  redundant  information  There  are  two  basic 
techniques  for  performing  recovery:  undo  logs  (Gray  et  ai  81 .  Verholstad  78],  and  intentions 
lists  [Lampson  81,  Verhofstad  781  The  representation  of  an  object  in  both  cases  is  divided 
into  two  pieces:  the  actual  value  of  the  object,  and  separate  recovery  information  (either  an 
undo  log  or  an  intentions  list). 

Undo  logs  work  as  follows:  When  an  activity  invokes  an  operation  on  an  object,  the  operation 
is  performed  on  the  value  of  the  object,  and  sufficient  information  is  recorded  in  the  object  s 
undo  log  so  that  the  effects  of  the  operation  can  be  undone  if  the  activity  that  executed  the 
operation  later  aborts.  For  example,  if  an  activity  executes  a  write  operation  on  an  object,  the 
old  value  of  the  object  might  be  saved  in  the  object's  undo  log  The  undo  log  for  an  activity  is 
simply  discarded  if  the  activity  commits. 

Intentions  lists  are  used  slightly  differently:  When  an  activity  invokes  an  operation  on  an 
object,  the  operation  is  simply  recor-^  d  in  the  intentions  lists  associated  with  the  object;  it  is 
not  actually  performed  on  the  value  of  the  object  until  the  activity  commits.  For  example,  if  an 
activity  executes  a  write  operation  on  an  object,  the  new  value  of  the  object  might  be  saved  in 
the  object's  intentions  list;  the  new  value  will  replace  the  old  value  only  if  the  activity  commits 
If  the  activity  aborts,  the  list  of  its  operations  is  discarded. 

A  detailed  description  of  these  techniques  and  alternative  storage  organizations  for  them  may 
be  found  in  (Verhofstad  78], 


1.1.2  Synchronization 

Many  protocols  have  been  developed  for  synchronizing  concurrent  activities  to  ensure 
serializability  (or  concurrency  control,  as  this  problem  is  called  in  tlie  literature  on  database 
systems  ■  see  [Bernstein  &  Goodman  81 J  for  a  survey  of  a  large  number  of  concurrency 
control  protocols.)  Most  are  variations  or  hybrids  of  two  simple  techniques:  two-phase 
locking  (Eswaren  el  al.  76]  and  multi-version  timestamping  [Reed  78]  We  discuss  these  two 
techniques  and  a  hybrid  below. 


1.1. 2.1  Locking  Protocols 

One  of  the  earliest  protocols  developed  for  concurrency  control  is  two  phase 
locking  [Eswaren  et  al.  76].  Two-phase  locking  works  as  follows.  Before  reading  an  object  X, 
an  activity  must  acquire  a  read  lock  on  X.  Similarly,  before  writing  an  object,  an  activity  must 
acquire  a  write  lock  on  the  object.  An  activity  can  acquire  a  lock  on  an  object  only  if  no 
concurrent  activity  holds  a  conflicting  lock  on  the  object.  In  addition,  once  an  activity 
releases  one  lock,  it  is  not  allowed  to  acquire  any  additional  locks. 
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Two  locks  on  an  object  conflict  il  one  is  a  write  lock.  This  definition  of  conflicting  locks 
ensures  that  at  most  one  activity  is  writing  an  object  at  a  time,  but  also  allows  multiple 
activities  to  read  an  object  concurrently. 

The  requirement  that  an  activity  not  acquire  any  more  locks  after  it  releases  a  lock  means  that 
activities  acquire  locks  in  a  two-phase  manner  (hence  the  name  of  the  protocol)  During  the 
growing  phase  an  activity  acquires  locks  without  releasing  any  locks  When  an  activity  first 
releases  a  lock,  it  enters  the  shrinking  phase.  During  this  phase  the  activity  releases  its  locks, 
but  may  not  acquire  any  more  locks.  As  is  shown  in  [Eswaren  el  al.  76,  Papadimitriou  79). 
two-phase  locking  ensures  that  activities  are  serializable  in  the  order  in  which  they  first 
release  locks. 

A  variant  of  two-phase  locking,  called  strict  two-phase  locking,  is  more  suited  to  the 
applications  of  interest  to  us.  Under  strict  two-phaso  locking,  activities  hold  all  locks  until  they 
commit  or  abort.  This  avoids  cascading  aborts  iWood  80).  a  problem  with  non-strict  two- 
phase  locking;  If  write  locks  are  released  and  then  an  activity  aborts,  any  activities  that  read 
the  values  written  by  the  aborted  activity  must  also  be  aborted.  In  addition,  strict  two-phase 
locking  permits  locks  to  be  acquired  dynamically  as  needed.  Non-strict  two-phase  locking 
may  require  more  advance  planning,  particularly  to  determine  when  an  activity  can  release  a 
lock. 

Strict  two- phase  locking  can  be  extended  to  nested  activities  as  follows:  Nested  activities 
form  a  natural  tree  structure,  with  each  activity  appearing  as  the  parent  of  its  subactivities. 
We  define  the  notions  of  ancestor,  proper  ancestor,  descendant,  and  proper  descendant  in 
the  usual  way.  The  locking  rules  for  nested  activities  are  defined  as  follows:  As  before,  an 
activity  must  acquire  a  read  (write)  lock  before  reading  (writing)  an  object.  An  activity  can 
acquire  a  lock  on  an  object  as  long  as  no  concurrent  non-ancestor  holds  a  conflicting  lock  on 
the  object.  When  an  activity  aborts,  its  locks  are  discarded.  When  an  nested  activity  commits, 
its  locks  are  inherited  by  its  parent;  when  a  top-level  activity  commits,  its  locks  are  discarded. 
Details  can  be  found  in  [Moss  SI.Liskov  et  al.  63);  a  proof  of  the  correctness  of  Moss's 
algorithm  is  given  in  (Lynch  83). 

1.1 .2.2  Timestamp- based  Protocols 

The  serialization  order  of  activities  attained  by  two-phase  locking  is  determined  dynamically 
by  the  order  in  which  activities  lock  objects.  In  contrast,  timestamp-based  protocols 
determine  the  serialization  order  statically  by  selecting  timestamps  for  activities  when  they 
start,  and  then  force  the  execution  of  activities  to  obey  this  order. 

Reed's  implementation  (Reed  78]  of  a  timestamp-based  protocol  works  as  follows;  An  activity 
is  assigned  a  unique  timestamp  when  it  begins  execution.  When  an  activity  wants  to  modify 
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an  object,  it  creates  a  new  version  of  the  object  A  version  of  an  object  has  two  timest.imp:, 
associated  with  it.  the  write  timestamp,  which  is  the  timestamp  of  the  activity  that  created  t'le 
version;  and  the  road  timestamp,  which  is  the  maximum  of  the  timestamps  of  activities  that 
have  read  the  version.  When  an  activity  with  timestamp  i  wants  to  read  an  object  it  selects 
the  version  of  the  object  with  the  largest  write  timestamp  less  than  /,  and  changes  the  read 
timestamp  of  the  version  to  the  maximum  of  its  current  value  and  i. 

Write  operations  sometimes  cannot  be  executed:  Suppose  an  activity  a  with  timestamp  t 
wants  to  write  an  object,  and  a  version  v  of  the  object  already  exists  with  write  timestamp  less 
than  t  and  read  timestamp  greater  than  t.  In  a  serial  execution  in  which  the  activities  execute 
in  timestamp  order,  a  must  come  between  the  activity  that  wrote  the  version  v  and  the  activity 
that  read  it.  If  a  is  allowed  to  write  the  object,  then  in  the  serial  execution  the  activity  that  read 
V  should  instead  read  the  value  written  by  a.  Thus,  the  write  operation  must  be  refused. 

To  avoid  cascading  aborts,  read  operations  sometimes  must  be  delayed:  If  an  activity  with 
timestamp  t  wants  to  read  an  object,  and  the  version  selected  was  written  by  an  activity  that 
has  not  yet  committed  or  aborted,  the  read  operation  must  wait  until  that  activity  completes. 
Otherwise,  if  the  activity  that  created  the  version  later  aborts,  the  reader  must  also  be  aborted. 

More  details,  and  in  particular  the  extension  of  the  protocol  to  cope  with  nested  activities,  can 
be  found  in  (Reed  78). 


1.1. 2. 3  Hybrid  Protocols 

Locking  and  timestamp-based  protocols  can  be  combined  to  yield  hybrid  protocols  that 
achieve  greater  concurrency  [DuBourdieo  82,  Chan  ef  ai.  82,  Bernstein  &  Goodman  81].  We 
divide  activities  into  two  classes:  read  only  activities,  which  never  modify  objects;  and  update 
activities. 

Update  activities  set  locks  on  objects  as  in  strict  two-phase  locking,  but  two  locks  conflict  only 
if  one  is  a  read  lock  and  the  other  is  a  write  lock;  a  write  lock  no  longer  conflicts  with  another 
write  lock.  As  with  Reed's  protocol,  each  write  operation  creates  a  separate  version,  and 
versions  have  two  timestamps.  Rather  than  choosing  timestamps  for  update  activities  when 
they  begin  executing,  however,  we  wait  until  they  attempt  to  commit.  Then,  using  a  Lamport 
clock  [Lamport  78],  we  ensure  that  the  timestamps  chosen  for  updates  give  a  serialization 
order  consistent  with  the  order  induced  by  the  locks.  The  order  of  conflicting  write  operations 
is  sorted  out  using  the  timestamps. 


Updaters  that  invoke  read  operations  always  read  the  version  with  the  largest  timestamp. 
Read-only  activities,  however,  may  read  older  versions,  permitting  them  to  run  without 
interfering  with  update  activities.  Timestamps  for  read-only  activities  are  chosen  when  they 
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start  executing.  When  a  read  only  activity  wants  to  read  an  object,  it  simply  selects  the 
version  with  the  largest  write  timestamp  less  than  the  activity's  timestamp.  A  proof  of  the 
correctness  of  this  protocol  can  be  found  in  (Bernstein  &  Goodman  83]. 


1.2  Atomic  Types 

Our  motivation  for  focusing  on  atomic  types  is  two  fold:  First,  it  is  important  to  understand  the 
interactions  among  independent  objects,  and  to  understand  what  constraints  must  be 
satisfied  by  objects  to  ensure  atomicity  of  activities.  Second,  by  using  information  about  the 
behavior  of  operations  provided  by  types,  we  can  achieve  greater  concurrency  than  can  be 
achieved  by  protocols  based  on  a  classification  of  operations  as  reads  and  writes.  In  this 
section  we  discuss  these  two  issues  in  more  detail.  In  the  first  part,  we  illustrate  the  problems 
caused  by  interactions  among  objects.  In  the  second  part,  we  discuss  how  user-defined 
atomic  types  can  be  used  to  increase  concurrency. 


1.2.1  Interactions  Among  Objects 

Each  of  the  protocols  discussed  in  the  previous  section  can  be  shown  to  ensure  atomicity  of 
activities.  Thus,  an  object  using  one  of  these  protocols  should  be  considered  "atomic." 
However,  as  the  example  below  illustrates,  objects  using  different  protocols  cannot 
necessarily  be  used  together  in  the  same  system. 

Consider  two  objects  X  and  Y,  each  with  read  and  write  operations,  and  each  with  initial  value 
0.  Suppose  that  X  is  implemented  using  two-phase  locking,  and  Y  is  implemented  using 
multi-version  timestamping.  Now  suppose  there  are  two  activities  A  and  B,  with  timestamps  1 
and  2,  respectively.  Consider  the  following  execution: 

B  reads  X,  receiving  0. 

B  writes  1  into  Y. 

B  commits. 

A  reads  Y,  receiving  0. 

A  writes  1  into  X. 

A  commits. 

This  execution  is  not  serializable:  In  a  serial  execution,  the  second  activity  should  see  the 
value  written  by  the  first,  but  both  A  and  B  read  the  initial  values  of  the  objects.  However,  the 
execution  is  atomic  at  each  object:  At  X,  B  is  serializable  before  A,  and  at  Y,  A  is  serializable 
before  B. 

The  problem  in  this  example  is  that  X  and  Y  use  incompatible  protocols  to  ensure  atomicity.  If 
both  objects  used  two-phase  locking,  or  both  used  multi-version  timestamping,  the  above 
execution  could  not  occur  and  atomicity  would  be  guaranteed.  As  we  will  discuss  in  Chapter 
4,  some  information  about  the  protocol  used  by  an  atomic  type's  implementation  must  be 
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reflected  in  the  type's  specification,  and  only  types  using  "compatible"  protocols  can  be  used 
in  the  same  system. 


1 .2.2  Type-specific  Concurrency  Control 

The  protocols  discussed  in  the  previous  section  were  developed  for  simple  data  types,  such 
as  files  and  relations,  with  read  and  write  operations  To  support  user  defined  types,  they 
must  be  extended  to  cope  with  arbitrary  operations.  The  primary  reason  for  making  such  an 
extension  is  increased  concurrency:  by  using  detailed  information  about  the  specifications  of 
the  operations  provided  by  types,  we  can  allow  concurrent  executions  that  must  be  forbidden 
if  operations  are  simply  characterized  as  reads  and  writes. 

Consider,  for  example,  a  bank  account  data  type,  with  operations  to  create  a  new  bank 
account  object  (with  an  initial  balance  of  0).  to  deposit  money  in  an  account,  to  withdraw 
money  from  an  account,  and  to  check  the  current  balance  of  an  account.  Now  consider  the 
following  concurrent  execution  of  two  activities,  A  and  B: 

A  deposits  $3  in  a  bank  account  X. 

B  deposits  $2  in  X. 

A  commits. 

B  commits. 

This  execution  is  clearly  serializable;  A  and  B  can  execute  serially  in  either  order  and  perform 
the  same  steps.  It  is  not  permitted,  however,  by  any  of  the  protocols  discussed  in  the  previous 
section;  A  and  B  both  update  X  (reading  the  current  balance,  and  writing  a  new  balance),  and 
so  cannot  access  X  concurrently. 

The  example  above  is  a  simple  illustration  of  a  general  phenomenon:  By  describing  a  system 
in  terms  of  abstract  objects  (rather  than  primitive  objects  with  read  and  write  operations),  we 
can  permit  greater  concurrency  than  would  otherwise  be  possible.  This  additional 
concurrency  may  be  essential  for  achieving  adequate  performance  in  an  application. 
Particularly  in  a  distributed  system,  activities  may  take  a  relatively  long  time  to  complete;  by 
permitting  more  concurrent  access  to  objects,  we  may  be  able  to  avoid  creating  bottlenecks 
in  the  system.  In  the  remainder  of  this  dissertation  we  will  provide  more  examples  of  this 
phenomenon,  and  will  show  how  implementations  of  objects  can  permit  high  levels  of 
concurrency. 

Achieving  the  kind  of  concurrency  illustrated  above  typically  requires  a  more  complex 
implementation.  It  may  be  most  effective  to  implement  a  system  initially  permitting  little 
concurrency,  for  example,  by  using  a  protocol  based  on  reads  and  writes.  If  certain  shared 
objects  can  then  be  identified  as  bottlenecks,  more  concurrent  (albeit  more  complex) 
implementations  can  be  substituted  for  the  types  defining  those  objects.  Of  course,  there  are 
limits  to  how  much  concurrency  an  atomic  type  can  permit.  One  of  the  results  of  this 
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dissertation  is  a  precise  definition  of  these  limits. 


1.3  Overview 

As  mentioned  earlier,  we  address  three  fundamental  questions  in  this  dissertation: 

-  What  is  an  atomic  type? 

-  How  can  we  specify  an  atomic  type? 

-  How  can  we  implement  an  atomic  type? 

To  answer  the  first  two  questions  we  must  generalize  existing  work  on  concurrency  control 
(or  serializability)  in  three  ways: 

•  Our  definition  of  atomicity  is  data  dependent:  It  is  based  on  an  explicit 
specification  of  the  desired  behavior  for  the  data  objects  used  by  activities.  This 
is  crucial  in  achieving  the  concurrency  required  by  applications. 

-  Our  definition  of  atomicity  is  integrated:  We  treat  both  serializability  and 
recoverability.  This  facilitates  the  description  and  verification  of  implementations 
of  atomic  objects,  which  necessarily  must  cope  with  both. 

•  We  focus  on  modularity  issues.  We  identify  local  properties  of  individual  objects, 
and  we  identify  the  conditions  under  which  different  kinds  of  objects  can  be 
combined  in  a  single  system  while  preserving  atomicity  of  activities. 

We  explore  three  local  properties,  each  of  which  is  optimal:  No  strictly  weaker  local  property 
suffices  to  ensure  atomicity.  The  three  properties  characterize  respectively  the  behavior  of 
the  three  classes  of  protocols  discussed  in  Section  1.1.2:  two-phase  locking  protocols,  in 
which  the  serialization  order  of  activities  is  determined  by  the  order  in  which  they  access 
objects;  multi-version  timestamp-based  protocols,  in  which  the  serialization  order  of  activities 
is  determined  by  a  pre  determined  total  order;  and  hybrid  protocols,  which  use  a  combination 
of  these  techniques. 

We  present  a  novel  locking  protocol  and  verify  its  correctness.  Our  protocol  generalizes 
previously  existing  protocols  in  two  ways:  It  permits  the  results  of  operations,  as  well  as  their 
arguments,  to  be  used  in  determining  the  appropriate  lock  mode,  and  it  handies  partial  and 
non -deterministic  operations.  In  addition,  we  describe  and  verify  the -implementation  of  both 
synchronization  and  recovery;  descriptions  of  previously  existing  protocols  are  limited  to 
synchronization  alone. 

Our  approach  to  specifying  atomic  types  permits  the  programmer  of  an  individual  activity  to 
ignore  how  atomicity  is  achieved.  To  reason  about  whether  an  individuai  activity  preserves 
consistency,  one  needs  only  the  serial  specification  of  each  object  used  by  the  activity,  and 
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the  knowledge  that  activities  are  atomic;  one  need  not  know  how  objects  cooperate  to  ensure 
atomicity. 

In  addition,  our  specification  framework  supports  an  approach  that  permits  the  concurrent 
specification  of  an  object  to  be  derived  systematically  from  a  specification  of  its  sequential 
behavior.  This  is  perhaps  the  most  significant  contribution  of  this  dissertation:  We  reduce  the 
problem  of  specifying  an  object  to  the  simpler  problem  of  specifying  how  it  should  behave  in 
the  absence  of  concurrency. 

Finally,  we  present  several  example  implementations  of  atomic  types,  illustrating  how  existing 
techniques  for  synchronization  and  recovery  can  be  extended  to  use  information  about  the 
specifications  of  objects  to  increase  concurrency.  We  also  discuss  linguistic  support  for 
atomic  types,  analyzing  the  advantages  and  disadvantages  of  several  alternative  approaches. 

Throughout  the  dissertation  we  use  a  model  that  permits  a  restricted  class  of  failures: 
Activities  can  abort,  but  objects  cannot  fail.  This  model  is  an  abstraction  of  real  systems,  and 
can  be  approximated  arbitrarily  closely  with  a  commitment  protocol  (eg.,  two-phase 
commit  [Gray  78,  Lampson  81]  or  three-phase  commit  [Skeen  82])  and  appropriate  use  of 
redundant  information  (e  g.,  stable  storage  [Lampson  81]). 

There  are  a  number  of  important  issues  that  we  do  not  address: 

•  We  do  not  investigate  particular  specification  languages  for  atomic  types:  rather, 
we  focus  on  the  underlying  formal  models  of  specifications  and  on  identifying 
desirable  semantic  properties  of  atomic  types. 

•  We  ignore  some  issues  raised  by  the  distributed  nature  of  applications,  such  as 
the  distinction  between  local  and  remote  data. 

'  We  do  not  consider  how  to  ensure  progress  in  the  face  of  deadlock,  starvation, 
and  failures. 


1.4  Related  Work 

Most  early  work  on  synchronizing  concurrent  processes  occurred  in  the  context  of  operating 
systems.  Numerous  linguistic  mechanisms  were  developed  (e  g.,  see  [Hoare  74,  Atkinson  & 
Hewitt  77,  Campbell  '  4  Habermann  74]),  permitting  modular  implementations  of 
synchronization  for  individual  operations  on  objects.  While  similar  implementation 
mechanisms  are  useful  for  supporting  atomicity,  the  concurrency  rules  for  atomic  actions  are 
different;  Synchronization  must  cope  with  interference  among  activities  invoking  multiple 
operations,  rather  than  just  interference  among  single  operations.  Furthermore,  there  was  no 
systematic  approach  for  coping  with  failures. 
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Specificution  and  proof  techniques  were  also  explored  (e  g.,  see  [Ovvicki  &  Gries  76,  Owicki  & 
Lamport  82.  Pnueli  77)).  Much  of  this  work  assumed  a  fixed  set  of  atomic  actions,  and  did  not 
consider  how  to  let  the  programmer  build  higher  level  atomic  actions  or  new  data  types.  In 
addition,  much  of  this  v^ork  did  not  consider  how  to  specify  and  verify  individual  modules. 

None  of  the  operating  systems  work  provided  a  systematic  solution  to  the  problem  of 
choosing  the  specifications  for  the  modules  in  a  system.  Our  specification  approach 
simplifies  the  problem  of  specifying  an  object  by  reducing  it  to  the  simpler  problem  of 
specifying  how  the  object  should  behave  in  the  absence  of  concurrency. 

The  trend  in  database  systems  was  quite  different.  Nested  atomic  actions  were  first  proposed 
by  Davies  [Davies  73]  (he  called  them  spheres  oi  control).  Single-level  transactions  were 
suggested  in  [Eswaren  et  al  76)  as  a  way  of  ensuring  consistency  of  databases  in  the 
presence  of  concurrency  and  failures.  While  Davies  discussed  atomic  actions  in  very  general 
terms  as  a  concept  lor  controlling  concurrency  and  failures.  Eswaren  et  ai  presented  a 
practical  implementation  based  on  two- phase  locking. 

Meanwhile,  work  at  the  University  of  Newcastle  on  recovery  blocks  [Randell  75]  investigated 
using  nested  atomic  actions  as  a  mechanism  for  localizing  the  effects  of  failures.  Recovery 
techniques  were  explored  in  depth,  particularly  for  building  user  defined  data 
types  [Verhofsfad  76,  .Anderson  el  al.  78).  The  problems  of  concurrency,  however,  were 
addressed  only  for  a  limited  class  of  data  types  (e  g.,  resource  managers  in  [Shrivastava  & 
Banatre  78],  and  objects  with  read  and  write  operations  in  [Best  &  Randell  81,  Best  82]).  In 
addition,  the  work  on  concurrency  assumed  the  use  of  a  locking  protocol,  and  did  not 
consider  other  kinds  of  protocols. 

As  work  on  distributed  systems  began  in  earnest  in  the  mid-l970's,  attention  was  focused  on 
atomic  actions  as  a  general  way  of  reducing  the  complexity  of  coping  with  concurrency  and 
failures.  Work  on  distributed  databases  and  file  systems  contributed  many  new  protocols  for 
implementing  atomicity  (see  [Bernstein  S  Goodman  81]  for  a  survey),  including  the  novel 
techniques  developed  by  Reed  [Reed  78]  Reed's  techniques  represent  the  first  detailed 
design  for  an  implementation  of  nested  atomic  actions. 

Since  then,  several  projects  (including  the  Argus  project  at  MIT  [Liskov  &  Scheifler  82].  work 
at  CMU  (Schwarz  &  Spector  82],  and  the  Clouds  project  al  Georgia  Tech  [Allchin  &  McKendry 
83])  have  focused  on  nested  atomic  actions  as  a  fundamental  concept  fer  organizing 
distributed  systems.  Moss  [Moss  81],  as  part  of  the  Argus  project,  developed  a  locking  based 
implementation  of  nested  atomic  actions.  The  Argus  project  has  also  explored  incorporating 
atomic  actions  into  a  programming  language  One  of  the  major  advantages  of  this  approach 
is  that  a  language  provides  a  more  flexible  notion  of  data  object  than  is  supported  by  a 
database  system  or  a  file  system  This  dissertation  explores  how  one  might  take  advantage  of 


this  flexibility. 


As  discussed  earlier,  our  work  on  specifying  atomic  types  generalizes  earlier  database  related 
work  on  concurrency  control  (e  g.,  jPapadimitriou  79])  in  three  ways:  First,  we  treat  both 
serializability  and  recoverability.  Second,  we  explore  how  to  analyze  user-specified  semantic 
information  to  achieve  greater  concurrency.  Third,  we  locus  on  local  properties  of  objects 
that  ensure  atomicity,  exploring  the  conditions  under  which  different  kinds  of  objects  can  be 
combined  while  still  ensuring  atomicity. 

Most  of  the  theoretical  work  relevant  to  atomicity  has  focused  on  concurrency  control,  and 
has  ignored  problems  of  recovery.  A  notable  exception  is  some  work  by  Lynch  [Lynch  83]. 
Lynch  defines  atomicity  lor  nested  actions,  presents  a  formalization  of  the  locking 
implementation  in  [Moss  81],  and  verifies  that  the  (formalization  of  the)  implementation 
ensures  atomicity.  While  Lynch  analyzes  serializability  and  recoverability  together,  she  does 
not  consider  data  dependent  implementations,  nor  does  she  address  modularity  issues. 

A  few  recent  papers  on  concurrency  control  [Bernstein  et  a/.  81,  Korth  81a.  Beeri  e(  a/.  83] 
address  the  problem  of  extending  concurrency  control  protocols  to  cope  with  arbitrary  user- 
defined  operations.  This  research  is  limited  in  several  ways,  however.  Most  important  is  the 
lack  of  consideration  of  modularity  issues.  The  focus  of  the  work  is  on  locking  protocols,  and 
the  interactions  among  different  kinds  of  protocols  are  not  considered  In  addition,  the 
papers  ignore  recovery,  and  require  the  operations  specified  by  the  user  to  be  functions. 
Non-determinism,  which  is  often  useful  to  avoid  over  specifying  abstractions,  is  not  permitted. 

We  have  not  considered  how  to  extend  all  existing  protocols  to  cope  with  user  defined 
operations.  For  example,  we  have  not  analyzed  optimistic  protocols  [Kung  &  Robinson  81]  in 
any  detail.  The  primary  reason  lor  this  is  that  optimistic  protocols,  by  their  very  nature,  do  not 
guarantee  internal  consistency  [Goree  83],  a  property  that  prevents  orphans  [Nelson  81]  from 
seeing  inconsistent  states.  Our  work  on  specifying  atomic  types  does  not  rule  out  optimistic 
implementations,  but  we  have  not  considered  in  detail  how  to  build  them. 

Other  protocols  that  we  have  not  considered  include  non-two  phase  locking  protocols  (e  g., 
see  (Silberschatz  &  Kedem  80,  Korth  81b])  and  protocols  for  implementing  replicated  objects 
(e  g.,  see  [Gifford  79])  Non  two  phase  locking  protocols,  while  useful  for  achieving  greater 
concurrency,  place  strong  restrictions  on  how  data  can  be  structured.  These  restrictions  may 
be  difficult  to  satisfy  in  the  general  class  of  applications  considered  here.  Replication 
techniques,  while  essential  for  reliability  and  availability,  are  beyond  the  scope  of  this 
dissertation.  Researchers  at  Cornell  [Skeen  S  Birman  83]  and  MIT  [Herlihy  84]  are  currently 
investigating  how  to  replicate  user-defined  data  objects. 

There  is  some  debate  over  whether  atomicity  is  too  strong  a  requirement,  and  whether  it 


permits  adequate  performance  Fischer  (Fischer  &  Michael  82]  has  illustrated  how  greater 
concurrency  can  be  achieved  for  a  distributed  directory  by  sacrificing  serializability.  The 
Grapevine  system  (Birrell  et  al  82.  Schroeder.  ei  ai  84]  also  violates  atomicity  in  places, 
primarily  for  performance  reasons  It  remains  to  be  seen  whether  the  performance 
advantages  of  violating  atomicity  are  worth  the  resulting  increase  in  complexity,  and  whether 
the  protocols  in  [Fischer  &  Michael  82]  and  (Birrell  et  ai  82]  can  be  generalized  and  applied  to 
other  systems. 

Lamport  (Lamport  76]  has  also  argued  that  atomicity  is  too  strong  a  requirement.  As  evidence 
for  this  claim,  he  presents  an  example  of  a  banking  system,  with  transfer  and  audit 
transactions.  Locking  implementations  of  this  system  do  not  perform  well:  audits  can  run  for 
a  long  time,  preventing  transfers  from  running  Lamport  presents  an  ad  hoc  protocol  that 
ensures  that  transfers  are  serializable,  and  that  each  audit  sees  a  consistent  state  of  the 
database.  His  protocol  permits  some,  though  not  all.  transfers  to  run  concurrently  with  an 
audit.  Protocols  developed  since  the  publication  of  [Lamport  76],  including  those  in  (Reed 
78],  (DuBourdieu  82],  and  [Chan  et  al.  82],  ensure  serializability  of  all  transactions  (not  just 
transfers)  Furthermore,  the  protocols  in  (DuBourdieu  82,  Chan  et  al.  82]  permit  all  transfers 
to  run  concurrently  with  an  audit,  thus  providing  greater  concurrency  than  Lamport's  ad  hoc 
protocol.  Unlike  Lamport's  protocol,  these  protocols  are  easily  applied  in  a  large  class  of 
similar  situations. 

A  detailed  comparison  of  these  and  other  papers  with  our  work  can  be  found  in  comments 
throughout  the  dissertation. 

1.5  Roadmap 

In  chapters  2  through  4  we  focus  on  specifications  of  atomic  types.  In  Chapter  2,  we  present 
our  formal  model  of  computations  and  specifications.  Then,  in  Chapter  3.  we  use  the  model 
to  define  atomicity  of  activities  Finally,  in  Chapter  4,  we  define  three  "local  atomicity 
properties:"  properties  of  individual  objects  that  ensure  atomicity  of  activities.  The  formal 
model  used  in  these  chapters  does  not  permit  activities  to  be  nested  We  expect  it  to  be 
relatively  easy  to  integrate  our  results  with  existing  formal  work  on  nested  activities  (e  g., 
[Lynch  83]),  but  do  not  do  so  in  this  dissertation. 

In  chapter  5,  we  connect  the  earlier  material  on  specifications  with  the  later  material  on 
implementations.  In  this  chapter  we  focus  on  one  of  the  local  atomicity  properties  defined 
earlier,  dynamic  atomicity.  We  present  an  algorithmic  description  of  a  novel  locking  protocol 
for  implementing  dynamic  atomic  objects  and  prove  that  it  is  correct. 


In  Chapters  6  and  7,  and  in  Appendix  A.  we  discuss  implementations  of  atomic  types.  In 
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Chaplei  6.  we  discuss  the  problems  that  must  be  solved  by  implementations  ot  atomic  types 
and  informally  discuss  liow  to  extend  the  material  on  specifications  to  cope  with  nested 
activities  Then,  we  present  the  approach  taken  in  Argus  [Liskov  el  al.  83]  to  cope  with  the 
problems  involved  in  implementing  atomic  types,  and  illustrate  several  limitations  of  this 
approach  In  Chapter  7  we  present  an  alternative  approach  that  avoids  some  of  the 
limitations  of  the  Argus  approach  The  appendix  contains  several  additional  examples 
illustrating  how  to  implement  user  defined  atomic  types,  and  further  illustrating  the 
differences  in  the  two  approaches  presented  in  Chapters  6  and  7. 

Finally,  in  Chapter  8.  we  summarize  our  results  and  discuss  further  work. 

An  index  for  the  technical  terms  defined  in  Chapters  2  through  5  is  contained  in  Appendix  B. 
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Chapter  Two 
System  Model 


In  this  chapter  we  describe  our  model  of  systems  We  begin  in  Section  2  1  by  describing  the 
components  of  a  system  and  defining  computations  Then,  in  Section  2  2  we  describe  how 
we  model  specifications  of  objects. 


2.1  Computations  and  Observations 

We  view  a  system  as  composed  of  activities  and  objects.  Activities  correspond  roughly  to 
processes  or  threads  of  control:  they  are  the  active  entities  in  the  system,  and  perform  tasks 
for  users.  Objects  contain  the  state  of  the  system:  they  provide  operations  by  which  activities 
can  examine  and  modify  the  system  state,  and  constitute  the  sole  path  by  which  activities  can 
pass  information  among  themselves.  We  will  typically  use  the  symbols  a,  b,  and  c  {possibly 
subscripted)  for  activities,  and  the  symbols  x,  y,  and  z  (again  possibly  subscripted)  for  objects. 

We  use  an  event-based  model  of  computation.  In  general,  the  events  in  which  we  are 
interested  are  events  that  occur  at  the  interface  between  objects  and  activities.  For  the 
remainder  of  this  chapter,  Chapter  3,  and  the  first  part  of  Chapter  4,  we  assume  that  an  event 
is  either  the  invocation  of  an  operation  on  an  object  by  an  activity,  the  termination  of  an 
invocation,  the  commit  (successful  completion)  of  an  activity  at  an  object,  or  the  abort 
(unsuccessful  completion)  of  an  activity  at  an  object.  A  note  on  terminology:  We  will  use  the 
term  "termination"  to  mean  the  end  of  the  execution  of  a  single  operation,  and  the  term 
"completion"  to  mean  the  end  of  the  execution  of  an  entire  activity.  Each  event  identifies  the 
activity  and  the  object  that  participate  in  it.  If  an  activity  (object)  participates  in  an  event,  we 
say  that  the  event  involves  the  activity  (object).  In  Chapters  4.2  and  4.3  we  will  augment  our 
model  with  additional  events  that  introduce  information  about  timestamps  for  activities. 

For  example,  suppose  x  is  an  object  that  is  intended  to  behave  like  a  set  of  integers,  with 
operations  to  insert  an  integer  in  x,  to  delete  an  integer,  and  to  check  for  membership  If  a  is 
an  activity,  example  events  include  the  following. 

•  a  invokes  insert  on  x  with  argument  3  (written  <insert(3).x,a>) 

an  invocation  of  an  operation  by  a  on  x  terminates  with  result  "ok"  (written 
<ok,x,a>) 

-  a  invokes  member  on  x  with  argument  7  (written  <member(7),x,a>) 

■  an  invocation  of  an  operation  by  a  on  x  terminates  with  result  "true"  (written 
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<ttue  x.a>) 

•  a  commits  at  x  (written  <commif,x,a>) 

A  computation  is  most  properly  viewed  as  a  partial  order  of  events  For  our  purposes  it 
suffices  to  restrict  our  attention  to  the  observable  behavior  of  a  system  We  model  an 
observation  of  a  system  as  a  finite  sequence  of  events 

For  example,  if  a  and  b  are  activities,  the  following  event  sequence  might  be  a  observation  of 
a  system  containing  a  set  object  x; 

<insert(3),x.a> 

<ok,x,a> 

<member(3),x.b> 

<commit,x,a> 

<true,x,b> 

<commit,x,b> 

If  h  IS  an  event  sequence  and  X  is  a  set  of  objects,  we  define  hjx  ("h  restricted  to  X")  to  be  the 
subsequence  of  h  consisting  of  all  events  in  which  objects  in  X  participate.  We  define  /)|4 
similarly  for  a  set  of  activities  A.  If  x  is  an  object  and  a  is  an  activity,  we  write  h|x  for  h|{x},  and 
b\a  for  n|{a}  We  also  define  commiUed{h)  to  be  the  set  of  activities  that  commit  in  h,  and 
aboried(h)  to  be  the  set  of  activities  that  abort  in  h.  Finally,  we  define  completed(h)  to  be  the 
set  of  activities  that  complete  (commit  or  abort)  in  h;  i  e  ,  compleled{h)  =  committed(h)  U 
aborted(h). 

We  will  use  the  following  notation  for  sequences:  The  symbol  denotes  concatenation  of 
sequences,  and  the  symbol  "A"  denotes  the  empty  sequence. 

We  include  here  two  technical  lemmas  The  first  lemma  asserts  the  commutativity  of  the 
restriction  operators: 

Lemma  2-1:  Suppose  X  and  Y  are  sets  of  objects,  and  A  and  B  are  sets  of 
activities.  Then 

ifhlxiiv  =  (h|y)|x  =  h|(xnK) 

2,  (h|A)|e  =  (h|e)|4  =  h|(4ne) 

3.  (h|X)|4  =  (h|4)|X 

The  second  lemma  asserts  the  independence  of  the  restriction  operators  and  the 
concatenation  operator  on  sequences: 

Lemma  2-2:  Suppose  S  is  a  set  of  obiects,  and  h  and  A  are  event  sequences. 

Then 

(h-MlS  =  (h|S)*(MS) 

The  same  property  holds  when  S  is  a  set  of  activities. 
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We  will  be  inlt’iested  in  those  event  sequences  tliat  ate  complete  in  the  lollowiny  sense  An 
event  sequence  h  is  cotnp/e/e  if  every  activity  either  completes  at  every  object  or  does  nothing 
at  the  obiect;  i.e  .  for  all  a  and  x,  either  a  G  conipictcd{h\x).  or  /)la|x  =  A. 

Not  all  event  sequences  make  sense  as  observations:  activities  are  intended  to  act  like 
seqLiential  processes  (Concurrency  within  an  activity  should  be  achieved  by  using  nested 
activities,  our  formal  analysis  of  atomicity  does  not  cover  nesting.)  Thus,  we  restrict  our 
attention  to  event  sequences  h  satisfying  the  following  conditions 

An  activity  must  wait  until  one  invocation  terminates  before  invoking  another 
operation  More  precisely,  let  op  cvents(h)  be  the  subsequence  of  n  consisting  of 
all  invocation  and  termination  events;  then  op  cvents[h\a)  must  consist  of  an 
alternating  sequence  of  invocation  and  termination  events,  beginning  with  an 
invocation  event  In  addition,  an  invocation  event  and  the  immediately 
succeeding  termination  event  must  involve  the  same  object. 

No  activity  both  commits  and  aborts  in  h  (at  the  same  or  different  objects):  i.e., 
commit(<i)  n  abort{h)  =  0. 

■  An  activity  cannot  commit  if  it  is  waiting  for  an  invocation  to  terminate,  and  an 
activity  cannot  invoke  any  operations  after  it  commits.  More  precisely,  if  a  G 
committedih).  then  h\a  consists  of  an  alternating  sequence  of  invocation  and 
termination  events,  ending  in  a  termination  event,  followed  by  some  number  of 
commit  events. 

Such  "well-formed"  event  sequences  will  be  called  histories:  in  the  remainder  of  this 
dissertation  we  will  be  concerned  only  with  histories,  not  with  arbitrary  event  sequences. 

These  restrictions  on  activities  are  intended  to  model  the  typical  use  of  atomic  activities  in 
existing  systems  An  activity  executes  by  invoking  operations  on  objects,  receiving  results 
when  the  operations  terminate.  Since  we  disallow  concurrency  within  an  activity,  an  activity  is 
permitted  at  most  one  pending  invocation  at  any  time.  After  successful  termination  of  all 
invocations,  an  activity  can  commit  at  one  or  more  objects. 

We  make  very  few  restrictions  on  aborted  activities;  for  example,  an  activity  can  continue  to 
invoke  operations  after  it  has  aborted.  We  have  two  reasons  for  avoiding  additional 
restrictions  First,  we  have  no  need  for  them  in  our  analysis.  Second,  and  most  important, 
additional  restrictions  might  be  too  strong  to  model  systems  with  orphans  (Nelson  81,  Goree 
83]  and  we  would  like  our  results  to  be  as  generally  applicable  as  possible. 

An  activity  is  not  allowed  to  commit  at  some  objects  and  abort  at  others:  this  requirement, 
called  atomic  commitment,  can  be  implemented  using  a  commitment  protocol  such  as  two- 
phase  commit  [Gray  78,  Lampson  81]  or  three-phase  commit  [Skeen  82). 
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2.2  Specifications 

Our  specilications  take  the  form  of  sets  of  sequences.  A  set  of  sequences  is  like  a  language, 
and  can  be  conveniently  described  by  a  machine  In  Section  2  2.1  we  define  siate  machines. 
which  we  will  use  for  describing  specifications.  Then,  in  Section  2.2.2,  we  define  our  model 
lor  specifications  of  objects.  Finally,  in  Section  2.2.3,  we  describe  how  properties  of  a  system 
can  be  inferred  from  the  specifications  of  its  components 


2.2.1  State  Machines 

Informally,  a  state  machine  consists  of  a  collection  of  slates  and  a  collection  of  transitions. 
The  transitions  can  be  used  to  change  the  state  of  the  machine  A  step  of  the  machine 
consists  of  a  single  transition;  the  machine  executes  steps  one  at  a  time. 

We  begin  with  some  notation.  We  use  the  notation  to  denote  a  partial  function.  The 
symbol  ±  denotes  "undefined,"  and  will  be  used  to  indicate  when  a  partial  function  is  not 
defined  for  a  given  set  of  arguments.  The  symbol  *,  as  mentioned  earlier,  denotes 
concatenation  of  sequences. 

Formally,  a  state  machine  M  consists  of:  a  state  domain  Sj^:  an  initial  state  Ij^  €  Sj^;  a 
collection  of  transitions  T^^:  and  a  partial  transition  function  ^  “*p 

The  transition  function  N.,  can  be  extended  to  finite  sequences  of  transitions  in  the  obvious 

M 

way;  i.e.,  if  T  is  a  transition  and  Tseq  is  a  finite  sequence  of  transitions,  then; 

N^(S,A)  =  S 

N^(S,  Tseq-T)  =  N|^(N^,{S.  Tseq).  T),  if  N^(S,  Tseq)  ± 

J.  otherwise 

If  Tseq  is  a  sequence  of  transitions  for  machine  M,  we  will  sometimes  use  the  notation  Tseq(S) 
for  N|^(S,  Tseq). 

If  Tseq(S)  *  ±,'Me  say  that  Tseq  is  defined  in  S.  We  say  that  a  sequence  of  transitions  Tseq 
IS  accepted  by  a  machine  M  if  Tseq  is  defined  in  l^^. 

We  may  easily  associate  a  set  of  sequences  with  a  machine:  Given  a  machine  M,  define  the 
language  of  M  (denoted  L(M))  to  be  all  finite  sequences  of  operations  that  are  accepted  by  M. 

Our  definition  of  a  state  machine  differs  slightly  from  the  usual  definition  of  an 
automaton  [Ginsburg  75].  Rather  than  introducing  the  notion  of  an  accepting  state,  and  then 
saying  that  a  sequence  Tseq  is  accepted  by  a  machine  M  if  Tseq(l^,)  is  an  accepting  state,  we 
have  found  it  convenient  for  the  examples  that  we  will  present  to  define  acceptance  as  above. 
Not  all  languages  (or  even  all  recursive  languages)  can  be  defined  by  one  of  our  state 
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nijcltinei  however  It  follows  Iroto  out  (ielintlioii  of  acceptance  that  the  language  of  a  state 
machine  is  preh»  closed.  If  a  sequence  s  is  in  the  language  of  a  machine  M,  then  every  finite 
prefix  of  ;i  IS  also  m  the  language  of  M. 

An  example  of  a  description  of  a  machine  appears  in  Figure  2  1:  the  language  of  the  machine 
consists  of  all  finite  alternating  sequences  of  a  s  and  b  s.  The  transition  function  is  described 
by  giving,  for  each  transition,  a  pr^.•condltlon  describing  the  set  of  states  in  which  it  is  defined, 
and  a  list  of  state  changes  caused  by  the  transition. 

States:  {a.  b.  i}  initially  i 

Transitions:  {a,  b} 

N(s,aJ: 

when  s  =  a  or  s  =  i 
changes  s  to  b 

N(s,b): 

when  s  =  bors  =  i 
changes  s  to  a 

Figure  2'1:An  example  machine. 


The  state  set  of  this  machine  is  {a,b,i}.  fn  later  examples  we  will  describe  sfafe  components, 
giving  a  name  and  domain  for  each  component.  This  indicates  that  the  state  set  is  the 
cartesian  product  of  the  sets  listed;  we  will  refer  to  the  component  name  of  state  s  as  s.name. 
In  descriptions  of  machines,  we  use  "when  <expr>,"  where  <expr>  is  a  boolean  expression,  to 
describe  preconditions  for  transitions.  If  the  precondition  is  omitted  from  the  description,  it  is 
assumed  to  be  true.  We  use  "changes  <list>,"  where  each  item  in  <list>  has  the  form  "<state 
component>  to  <expr>,"  to  describe  the  relationship  between  the  state  before  a  transition  and 
the  state  after  the  transition.  Components  not  listed  are  assumed  to  be  unchanged.  We  will 
also  use  the  form  "if  <expr>  then  <changes>  else  <changes>"  to  describe  conditional 
changes. 


2.2.2  Specifications  of  Objects 

Assuming  that  all  executions  of  a  system  are  atomic,  consistency  is  preserved  if  every  activity 
preserves  consistency  when  executed  in  isolation  with  no  failures  To  check  this  property  we 
only  need  to  know  how  each  object  and  activity  behaves  in  a  sequential,  failure  free 
environment  We  have  found  it  convenient  to  specify  an  object  by  first  describing  the  object  s 
sequential,  failure-free  behavior,  and  then  describing  how  the  object  controls  concurrency 
and  failures  to  ensure  atomicity.  We  reflect  this  two  stage  process  directly  in  our  model:  A 
specification  of  an  object  x  consists  of  two  parts,  the  sprui'  specilication  (denoted  x. serial). 
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and  the  he/i.ivM/a/ y/ieci/it  a/ion  (denotef)  *  Itciunnu)  The  serial  specification  of  an  object  is 
intended  to  model  the  acceptable  behavior  of  the  object  in  a  sequential,  failure-free 
environment,  while  the  behavioral  specification  describes  how  the  object  supports  atomicity 

The  behavioral  specification  of  an  object  *  describes  the  acceptable  histones  involving  x.  and 
consists  of  a  set  of  complete  histories  h  such  that  every  event  in  h  involves  x.  In  Section 
2.2.3  we  will  describe  how  the  behavioral  specifications  of  objects  constrain  the  behavior  of  a 
system. 

It  is  convenient  for  the  serial  specification  of  an  object  to  be  in  a  slightly  different  form  from  its 
behavioral  specification  Instead  of  a  set  of  complete  histories,  we  will  use  a  set  of  operation 
sequences.  An  operation  is  a  pair  consisting  of  an  invocation  and  a  termination  event.  In 
addition,  an  operation  identifies  the  object  on  which  it  is  executed.  An  operation  does  not 
identify  an  activity;  we  have  found  no  need  for  the  serial  specification  of  an  object  to  vary 
depending  on  which  activity  executes  an  operation,  and  indeed  find  it  more  convenient  to 
describe  the  serial  specification  in  a  way  that  is  independent  of  activities. 

We  often  speak  informally  of  an  "operation"  on  an  object,  as  in  "the  insert  operation  on  a  set 
object."  An  operation  in  our  formal  model  is  intended  to  represent  a  single  execution  of  an 
"operation"  as  used  in  the  informal  sense.  For  example,  the  following  might  be  an  operation 
(in  the  formal  sense)  on  a  set  object  x: 

x:<insert(3),ok> 

This  operation  represents  an  execution  of  insert  on  x  with  argument  "3"  and  result  "ok." 

A  state  machine  is  a  convenient  tool  for  describing  the  serial  specification  of  an  object.  We 
define  the  transitions  of  a  machine  to  be  the  operations  on  the  object,  and  choose  a  transition 
function  such  that  the  language  of  the  machine  is  the  desired  set  of  operation  sequences. 
For  example,  the  state  machine  in  Figure  2-2  describes  the  serial  specification  of  a  set  object 
X.  A  set  object  provides  three  operations:  insert,  delete,  and  member.  Insert  adds  a  specified 
item  to  the  set  object.  Delete  removes  a  specified  item  from  the  object.  Member  determines 
whether  a  specified  item  is  an  element  of  the  set  object. 

The  reader  may  check  that  the  following  operation  sequence  is  in  the  language  of  the  state 
machine  in  Figure  2-2; 

x:<insert(3),ok> 

x;<member(3),true> 

The  following  sequence,  however,  is  not: 

x;<insert(3),ok> 

x;<member(3),false> 

Another  example,  the  serial  specification  of  a  semiqueue  object  y,  appears  in  Figure  2-3.  A 
semiqueue  object  provides  two  operations:  enq  and  deq  Enq  adds  a  specified  item  to  the 
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Slates:  sets  of  items  initially  0 

Transitions:  {x:<insert(i),ok>,  x:<delete(i),ok>,  x:<member(i),b>:  i  is  an 
Item  and  b  is  a  boolean} 

N(s.x;<insert(i),ok>). 

changes  s  to  sU{i} 

N(s,x:<delete(i),ok>): 
changes  sto  s-{i) 

N(s,x:<member(i)  ,true>). 
when  i€s 

N{s,x:<member(i),false>): 
when  i€s 

Figure  2-2:Serial  specification  of  a  set  object  x. 


semiqueue  object.  Deq  nondeterministically  chooses  an  item  in  the  semiqueue,  deletes  it, 
and  returns  it:  deq  is  not  defined  if  the  semiqueue  is  empty.  Semiqueues  are  like  multisets, 
rather  than  sets,  in  that  an  item  can  appear  more  than  once.  We  will  return  to  this  example  in 
later  chapters,  first  precisely  describing  the  concurrency  that  can  be  permitted  by  an  object 
with  this  serial  specification,  and  then  illustrating  how  semiqueues  can  be  implemented  to 
achieve  this  level  of  concurrency. 

States:  multisets  of  items  it\itialty  0 

Transitions:  {y:<enq(i),ok>,  y:<deq,i>;  i  is  an  item) 

N(s.y:<enq(i),ok>): 

changes  sto sU{i} 

N(s  y:<deq,i>): 
when  i€s 
changes  s  to  s  {i} 

Figure  2-3:Serial  specification  of  a  semiqueue  object  y. 


2.2.3  Behavior  of  a  System 

The  behavior  of  a  system  is  determined  by  the  behaviors  of  its  components  and  the 
interconnections  among  the  components  The  specification  of  a  component  constrains  the 
behavior  of  the  component,  and  indirectly  constrains  the  behavior  of  the  system.  In  this 
section  we  describe  how  constraints  on  the  behavior  of  a  system  can  be  inferred  from  the 
specifications  of  the  system's  components. 


The  behavioral  specification  of  an  object  ».  us  described  above,  is  a  set  of  complete  histories 
involving  >.  Similarly,  we  define  the  behavioral  specification  of  an  activity  a  (denoted 
a. behavior)  to  be  a  set  of  complete  histories  involving  a. 

We  define  the  behavior  of  a  system  to  be  all  complete  histories  h  such  that,  for  alt  a  and  x,  h|a 
C  a  behavior  and  h|)t  C  x. behavior.  In  other  words,  any  history  of  a  system  must  be  permitted 
by  the  specification  of  each  of  the  system  s  components  Notice  that  the  behavioral 
specification  of  each  component  describes  how  the  component  constrains  the  occurrence  of 
events  in  which  it  participates,  and  places  no  constraints  on  the  occurrence  of  other  events. 

Many  papers  have  been  published  on  models  for  distributed  systems.  Recently,  Stark  (Stark 
84]  has  been  studying  how  to  model  specifications  of  modules  in  distributed  and  concurrent 
systems  He  has  developed  a  general  framework  incorporating  notions  of  composition  and 
abstraction;  in  particular,  his  notion  of  ‘■observations"  is  similar  to  ours,  as  is  his  notion  of 
composition  of  behaviors  for  components  of  a  system.  Howevet ,  he  does  not  consider  well- 
formedness  conditions  on  observations  specific  to  any  particular  applications;  in  addition,  his 
desire  to  be  able  to  specify  and  to  model  eventuality  properties  forces  him  to  consider  infinite 
observations,  complicating  his  framework.  A  framework  such  as  his.  however,  could  be  used 
to  develop  a  more  rigorous  formalization  of  our  model  and  associated  results. 
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Chapter  Three 
Global  Atomicity 

In  this  chapter  we  develop  a  formal  definition  of  atomicity  Our  goal  is  to  understand  how 
objects  can  cooperate  to  ensure  that  all  complete  histories  in  a  system  s  behavior  are  atomic 
The  definitions  in  this  chapter  apply  to  all  histories,  however,  not  just  to  complete  histones  In 
Chapter  4  we  will  concentrate  on  complete  histories,  and  will  look  at  several  different  ways  in 
which  objects  can  cooperate  to  ensure  atomicity  of  complete  histories  In  Chapter  5  we  will 
consider  prefixes  of  complete  histories,  and  illustrate  how  an  implementation  of  an  object  can 
ensure  atomicity  in  an  on  line  manner. 

The  remainder  of  this  chapter  is  divided  into  two  sections.  In  the  first,  we  develop  our 
definition  of  atomicity  Then,  in  the  second,  we  compare  our  definition  to  common  definitions 
of  serializability  in  the  literature,  illustrating  some  limitations  of  the  model  used  in  those 
definitions. 

3.1  Definitions 

Informally,  a  history  of  a  system  is  atomic  if  it  is  equivalent  to  a  sequential,  failure-free 
execution  of  the  committed  activities  in  the  history.  The  serial  specifications  of  objects 
describe  the  acceptable  behavior  of  the  system  in  a  sequential,  failure-free  environment. 
Since  serial  specifications  are  sets  of  operation  sequences,  not  sets  of  histories,  we  need  to 
establish  a  correspondence  between  histories  and  operation  sequences.  The  paragraph 
below  provides  the  necessary  definitions. 

We  say  that  a  history  is  serial  if  events  for  different  activities  are  not  interleaved  If  h  is  a  serial 
history,  and  a,,  ...,  are  the  activities  in  h  in  the  order  in  which  they  appear,  then  we  can 
write  h  as  h|aj»...*h|a^.  We  say  that  a  history  h  is  fai/ure-free  if  aOorfed(n)  =  0.  Now,  if  his  a 
serial  failure-free  history,  we  define  opseq{h)  as  follows:  Opseq{h\a).  for  an  activity  a,  is  the 
operation  sequence  obtained  from  h|a  by  pairing  each  invocation  event  with  its 
corresponding  termination  event,  and  discarding  commit  events  and  pending  invocation 

events.  Let  a, . be  the  activities  in  h  in  the  order  in  which  they  appear;  then  opseq(h)  is 

defined  to  be  opseq{h\a  j)’ ...•cpseq{h\a^).  Opseq{h).  for  a  serial  failure-free  history  h,  is  the 
operation  sequence  corresponding  to  h. 

For  example,  if  h  is  the  serial  failure-free  history 


<insert(3).x,b> 

<ok,x,b> 

<commif.x,b> 

<member{3),x.a> 

<true,x,a> 

<commit,x,a> 

then  opseq(h)  is  the  operation  sequence 

x:<insert(3),  ok> 
x.<member(3),  true> 

Similarly,  if  h  is  the  serial  failure  free  history 

<insert{3),x,a> 

<ok,x,a> 

<delete(2).x,a> 

then  opseq(h)  is  the  operation  sequence 

x:<insert(3),  ok> 

Notice  that  we  do  not  restrict  the  domain  of  opseq  to  complete  histories,  we  will  need  to  apply 
it  to  incomplete  histories  in  Chapter  5. 

We  say  that  two  histories  h  and  k  are  equivalent  if  every  activity  performs  the  same  steps  in  h 
as  in  k;  i.e.,  if  h|a  =  k\a  for  every  activity  a.  We  also  say  that  a  serial  failure  free  history  h  is 
acceptable  at  x  if  opseqih\x)  €  x. serial',  in  other  words,  if  the  sequence  of  operations  in  h 
involving  x  is  permitted  by  the  serial  specification  of  x.  A  serial  failure-free  history  is 
acceptable  if  it  is  acceptable  at  every  object  x. 

For  example,  suppose  that  x  is  an  integer  set  object  with  a  serial  specification  as  given  in 
Figure  2-2.  If  b  is  the  serial  failure-free  history 

<insert(3),x,b> 

<ok,x,b> 

<commit,x,b> 

<member(3),x,a> 

<true.x,a> 

<C0(nmit,x,a> 

then  opseq{h)  is  the  operation  sequence 

x:<insert(3),ok> 

x:<tnember(3),true> 

which  is  in  x. serial.  Thus,  h  is  acceptable.  On  the  other  hand,  if  h  is  the  history 

<insert(3),x,b> 

<ok.x,b> 

<commit,x,b> 

<member(3),x,a> 

<false,x.a> 

<commit,x.a> 

then  h  is  not  acceptable,  since  opseq{h)  is  not  in  x.  serial. 


If  n  IS  a  liistory  and  r  is  a  total  ordei  on  activities,  we  define  M‘ruti(h.  7)  to  be  the  serial  lustory 

equivalent  to  h  in  which  activities  appear  in  the  order  T.  If  a , . are  the  activities  in  h  m  the 

order  T.  then  serial{h,  T)  =  h|a|*. 

The  following  lemma  asserts  the  independence  of  the  serializing  operator  and  the  restriction 
operator. 

Lemma  3-1:  If  h  is  a  history.  X  is  a  set  of  objects  and  T  is  a  total  order  on 
activities,  then  senal{h\X,  T)  =  sprial(h.  7)|x. 

Proof:  Let  a^.  .  .  be  the  activities  in  h  in  the  order  7.  The  following  equalities 
show  the  desired  result: 

ser/a/(rt|X,  T)  =  (h|X)|a  |*...*(h|X)|a^ 

=  (hla,)|X*  ..‘(hla^HX 
=  (h|a,*  .•hla^)|X 
=  senal{h.  T)|X 

The  first  line  follows  from  the  definition  of  serial.  The  second  line  follows  from 
Lemma  2-1,  and  the  third  line  from  Lemma  2-2.  The  fourth  line  again  follows  from 
the  definition  of  serial. 

If  T  is  a  total  ordering  of  activities,  we  then  say  that  a  failure  free  history  h  is  serializable  in  the 
order  T  if  seriaHh,  T)  is  acceptable.  We  say  that  a  failure-free  history  h  is  serializable  if  there 
exists  a  total  order  T  on  activities  such  that  h  is  serializable  in  the  order  T.  In  other  words,  a 
failure-free  history  is  serializable  if  it  is  equivalent  to  an  acceptable  serial  history. 

For  example,  if  h  is  the  failure-free  history 

<member(3),x,a> 

<insert(3),x,b> 

<ok,x,b> 

<true,x,a> 

<commit.x,b> 

<commif,x,a> 

and  T  is  a  total  order  in  which  ft  precedes  a,  then  h  is  serializable  in  the  order  7:  Serial(h.T)  is 
the  history 

<insert(3),x,b> 

<ok,x,b> 

<commit.x.b> 

<member{3).x,a> 

<true,x.a> 

<commjt,x,a> 

and.  as  illustrated  above,  this  history  is  acceptable. 

Note  that  serializability  is  defined  for  all  failure-free  histories,  not  just  those  that  are  complete. 
We  will  consider  incomplete  histories  in  Chapter  5. 
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Letnnta  3  2  describes  llie  rtlation  between  senali^ubility  ot  a  liistoiy  and  senalizatulity  of  its 
subhistories  at  each  object. 

Lemma  3-2:  If  h  is  a  history  and  r  is  a  total  order  on  activities,  h  is  serializable  in 
the  order  T  if  and  only  if,  for  every  object  *,  hi*  is  serializable  in  the  order  T. 

Proof;  Follows  easily  from  the  definitions  and  Lemma  3  1 , 

Now,  define  permanent(h)  to  be  t'i\conim'tted(h)  We  then  say  that  h  is  atomic  if  permaneni(ti) 
is  serializable  Thus,  we  formalize  recoverability  by  throwing  away  events  for  non  committed 
activities,  and  requiring  that  the  committed  activities  be  serializable. 

For  example,  if  *  is  an  integer  set  as  above  and  h  is  the  history 

<member(3),x,a> 

<insert(3).x,b> 

<ok,x,b> 

<true,x,a> 

<commit,x,b> 

<delete(3),x,c> 

<ok,x,c> 

<commit,x,a> 

<aborl,x,c> 

then  permanent{h)  is  the  failure- free  history 

<member(3),x,a> 

<insert(3).x,b> 

<ok,x,b> 

<true,x,a> 

<commit,x,b> 

<commit,x.a> 

which,  as  illustrated  above,  is  serializable  Thus,  h  is  atomic. 

On  the  other  hand,  the  history 

<member(2),x,a> 

<true.x,a> 

<commit,x,a> 

is  not  atomic,  since  x  serial  does  not  contain  the  sequence 

x:<member(2),  true> 

The  final  lemma  asserts  that  permanent  commutes  with  restriction  to  an  object  for  complete 
histories. 

Lemma  3-3;  If  h  is  a  complete  history  and  x  is  an  object.  permanenl{h)\x  * 
permanent(h\x). 

Proof:  We  show  that  permanent(h)lx  is  a  subsequence  of  permanerjf(h|x);  a 
similar  argument  shows  that  permanent(hlx)  is  a  subsequence  of  permanenl(h)lx. 
Since  both  histories  are  subsequences  of  h.  it  suffices  to  show  that  every  event 
appearing  in  permaneni(ti)lx  also  appears  in  permaneni(h{x).  Suppose  e  is  an 
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event  in  ptv(i)jnen,'(n)|k  Let  a  be  the  activity  that  participates  m  e  B,  the 
definition  of  restriction,  *  must  also  participate  in  e  Thus  e  also  appears  in  h|« 

Since  e  appears  m  permancnHh)\x,  a  must  commit  in  h:  since  h  is  complete,  and 
Ar|a|i  *  A  d  must  commit  in  n|»  Thus,  e  appears  in  permanent(h|*). 

Our  definition  of  atomicity  is  similar  to  the  definition  of  senalizability  in  [Papadimitnou  7‘j] 
where  It  IS  assumed  that  some  underlying  recovery  mechanism  handles  aborts  of  activities, 
and  the  formal  analysis  considers  only  events  for  committed  activities  It  is  different  m  that  we 
include  events  for  aborted  and  active  activities  in  our  formal  model,  as  we  will  discuss  in 
Chapter  5  this  facilitates  the  precise  description  of  online  support  lor  recoverability  It  also 
differs  in  that  the  definition  of  senalizability  is  based  on  user-supplied  specifications  of  the 
acceptable  serial  behavior  of  objects,  rather  than  a  free  interpretation  as  in  [Papadimitnou 
79]  As  we  will  discuss  m  Section  4  4.t ,  this  enables  us  to  achieve  more  concurrency 

3.2  Limitations  of  the  Scheduler  Model 

Our  model  is  slightly  different  from  that  used  in  much  of  the  literature  on  concurrency  control, 
including  those  papers  that  consider  user  specified  operations  (e  g.,  [Papadimitriou 
79.  Bernstein  ef  al  SI  .Korth  81a.  Been  et  ai  83]).  That  model,  which  we  will  call  the 
scheduler  model,  is  pictured  in  Figure  3-1. 
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Figu  re  3- 1  :The  scheduler  model. 


The  boxes  on  the  left  represent  transactions,  which  submit  invocations  to  the  scheduler  in  the 
middle  The  scheduler  determines  the  order  in  which  to  run  operations  invoked  by 
transactions,  and  submits  the  invocations  in  that  order  to  the  storage  module  on  the  right, 
which  processes  the  operations  and  returns  their  results  to  the  transactions  (The  storage 
module  behaves  similarly  to  the  state  machines  that  we  use  to  describe  serial  specifications.) 
The  problem  addressed  in  the  papers  cited  above  is  to  analyze  the  properties  of  the  scheduler 
module  The  problem  that  we  address  is  slightly  different:  we  analyze  the  properties  of  the 
interface  represented  by  the  dotted  line 


The  scheduler  model  imposes  unnecessary  limitations  on  the  problem  as  the  loHowmg 
example  illustrates  Let  /  be  a  first  in  first  out  queue  object  v^itti  a  serial  specification  as 
described  by  the  machine  in  Figure  3  2  A  FIFO  queue  object  provides  two  operations:  cnq 
and  oei;  t  nq  appends  a  specified  item  to  the  back  of  the  queue.  Deq  removes  and  returns 
the  Item  at  the  front  of  the  queue:  if  the  queue  is  empty  deq  signals  empq  Now  consider  the 
following  history: 

<enqueue(1).z,a> 

<ok.z.a> 

<enqueue(2),z.b> 

<ok.z.b> 

<commit.z,a> 

<commit,z,b> 

<dequeue,z,c> 

<2,z,c> 

<dequeue,z,c> 

<1  .z.c> 

<commit,z,c> 

Note  that  this  history  is  atomic:  The  equivalent  history  with  a.  b.  and  c  in  the  order  b  a  c  is 
acceptable. 

States  sequences  of  items  initially  A 

Transitions:  {z:<enq(i),ok>,  z:<deq.i>,  z:<deq,empty>:  i  is  an  item) 

N(s.z:<enq{i).ok>): 

changes  s  to  sm 

N(s,z:<deq.i>): 
when  s  =  i*s’ 
changes  s  to  s' 

N(s.z:<deq,empty>): 
when  s  =  A 

Figure  3-2:Serial  specification  of  a  FIFO  queue  object  z 

Now  consider  what  happens  in  the  scheduler  model  This  history  cannot  be  produced  using 
the  scheduler  model  (assuming  that  the  order  of  termination  events  corresponds  to  the 
scheduling  order)  If  it  were,  the  state  of  the  storage  module  alter  a  and  b  commit  would  be 
1*2  (reading  from  front  to  back)  then  c  would  have  to  receive  l  before  2.  not  2  before  i 
Thus,  the  scheduler  model  restricts  the  histones  that  can  occur,  and  indeed  rules  out  some 
histories  that  appear  "atomic." 

The  cause  of  this  limitation  of  the  scheduler  model  is  its  fixed  internal  structure  It  imposes  a 
fixed  interpretation  on  all  histones,  based  on  the  interface  between  the  scheduler  and  the 


SlOKiye  /nodule  In  co/il/nol  we  do  not  inlorpiet  events  in  le/nis  ol  some  lower  level  model  ot 
execution  Opseq  provides  a  Kind  of  "operational"  interpretation,  but  we  use  it  only  for  serial 
histones,  not  for  all  histories. 

The  scheduler  model  was  intended  to  be  used  to  study  the  concurrency  control  problem, 
which  IS  but  one  aspect  of  the  more  general  problem  of  ensuring  atomicity.  Our  model  was 
designed  to  be  used  to  study  atomicity  in  as  general  a  setting  as  possible  thus  we  needed  to 
make  our  model  as  abstract  as  possible.  This  means  that  we  avoid  the  limitations  of  the 
scheduler  model  illustrated  above,  but  also  means,  since  our  model  incorporates  less  fixed 
structure,  that  it  may  be  more  difficult  to  verify  implementations. 


Chapter  Four 
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Local  Atomicity  Properties 


We  are  interested  m  ways  of  ensuring  that  all  possible  histones  oi  a  system  are  atomic  As 
discussed  in  Chapter  2  the  histones  of  a  system  are  constrained  hy  the  specifications  of  the 
components  of  the  system  In  this  chapter  we  investigate  several  properties  of  individual 
objects  that  ensure  atomicity  of  activities  using  the  objects  We  call  such  properties  local 
atomicity  properties  More  precisely,  a  iocal  atomicity  property  is  a  property  P  of 
specifications  of  objects  such  that  the  following  is  true  If  the  specification  of  every  object  in 
system  satisfies  P,  then  every  history  m  the  system's  behavior  is  atomic. 

The  problem  that  must  be  solved  in  designing  a  local  atomicity  property  is  to  ensure  that  the 
objects  agree  on  at  least  one  serialization  order  for  the  committed  activities  Solving  this 
problem  can  be  difficult  because  each  object  is  aware  of  only  the  events  m  which  it 
participates  In  other  words,  each  object  has  purely  local  information:  no  object  has  complete 
information  about  the  global  computation  of  the  system 

As  discussed  m  Chapter  1,  there  are  many  different  protocols  that  ensure  agreement  among 
objects,  and  these  protocols  are  not  always  compatible.  In  this  chapter  we  present  three 
different  local  atomicity  properties,  highlighting  the  way  m  which  agreement  is  reached.  We 
also  show  that  each  property  is  optimal,  in  a  sense  to  be  defined  below  Our  optimality  results 
imply  that  no  local  property  is  both  necessary  and  sufficient  for  global  atomicity. 

The  three  properties  presented  in  this  chapter  provide  formal  characterizations  of  the 
behavior  of  three  different  classes  of  protocols,  exemplified  by  the  three  types  of  protocols 
(two  phase  locking,  multi-version  timestamping,  and  hybrid  methods)  discussed  in  Chapter  1, 
Each  of  the  properties  is  based  on  user  supplied  specifications  of  the  acceptable  serial 
behavior  of  objects,  thus  permitting  implementations  that  achieve  greater  concurrency  than  is 
possible  when  operations  are  simply  characterized  as  reads  and  writes 

The  remainder  of  this  chapter  is  divided  into  four  sections  In  each  of  the  first  three  we 
present  a  different  local  atomicity  property.  In  the  fourth  we  conclude  with  some  remarks  on 
classes  of  atomic  types  and  related  work 
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4.1  Dynamic  Atomicity 

Two  phase  locking  protocols  [Eswaren  el  ai  76.  Bernstein  cl  at  81.  Kortti  8laj  determine  a 
serialization  order  for  activities  dynamically,  based  on  the  order  in  which  activities  invoke 
operations  and  obtain  locks  on  objects  Our  first  local  atomicity  property  characterizes  the 
behavior  of  protocols  including  two  phase  locking  protocols  which  are  dynamic  m  this 
sense  We  call  this  property  dynamic  atomicity 

Inlormally  stated,  the  fundamental  property  of  protocols  characterized  by  dynamic  atomicity  is 
the  following  If  the  sequence  of  operations  executed  by  one  committed  activity  conflicts  with 
the  operations  executed  by  another  committed  activity  then  some  of  the  operations  executed 
by  one  of  the  activities  must  occur  after  the  other  activity  has  committed  Locking  protocols 
(and  all  pessimistic  protocols)  achieve  this  property  by  delaying  conflicting  operations, 
optimistic  protocols  [Kung  &  Robinson  81)  achieve  this  property  by  allowing  conflicts  to 
occur,  but  abort'ng  conflicting  activities  to  prevent  conflicts  among  committed  activities. 

The  remainder  of  this  section  is  divided  into  two  subsections  In  the  first,  we  present  dynamic 
atomicity  and  prove  that  it  is  a  local  atomicity  property  In  the  second,  we  define  optimality, 
and  show  that  dynamic  atomicity  is  optimal.  In  Chapter  5.  we  will  examine  dynamic  atomicity 
in  greater  detail,  describing  locking-based  implementations  and  verifying  that  dynamic 
atomicity  indeed  characterizes  their  behavior.  We  will  also  illustrate  the  limitations  of  locking, 
showing  that  there  are  useful  non  locking  protocols  that  are  characterized  by  dynamic 
atomicity 


4.1.1  Definition  of  Dynamic  Atomicity 

We  can  describe  dynamic  atomicity  precisely  as  follows.  If  h  is  a  history,  define  precedes[h) 
to  be  the  following  relation  on  activities:  <a.b>(iprecedes[h)  if  and  only  if  there  exists  an 
operation  invoked  by  b  that  terminates  after  a  commits.  The  events  need  not  occur  at  the 
same  object  The  relation  precedes(h)  captures  the  concept  of  an  operation  being  delayed:  If 
<a.b>Gprecedes(/r),  then  some  operation  executed  by  b  was  delayed  in  h  until  after  a 
committed. 

For  example,  if  x  is  a  set  object  as  before,  and  h  is  the  history 

<insert(2),x,a> 

<ok,x,a> 

<member(3),x,b> 

<false,x,b> 

<commif,x,b> 

<commit,x,a> 

then  precedes(h)  is  the  empty  relation,  while  if  h  is  the  history 


<insert(2),x,a> 

<ok,x,a> 

<member(3),x,b> 

<commit,x,a> 

<false,x,b> 

<commit,x,b> 

then  precedes{h)  contains  the  pair  <a,0>.  Note  that,  for  any  history  h.  prccedes(h)  is  a  partial 
order. 

The  following  lemma  provides  the  key  to  our  definition  of  dynamic  atomicity 

Lemma  4- 1 :  If  h  is  a  history  and  x  is  an  obtect.  then  precedes(h|x)  C  preccdes(h) 

If  n  is  a  history  of  the  system,  each  object  has  only  partial  mformation  about  precedes{h) 
However,  if  each  object  x  ensures  local  serializability  in  all  orders  consistent  with 
precedes(n|x)  we  are  guaranteed  global  senalizability  in  all  orders  consistent  with 
prt^ccdes(h)  To  be  precise,  we  have  the  following  definition  of  dynamic  atomicity  We  say 
that  a  history  h  is  ayna'nic  alonnc  if  permanen!{h)  is  serializable  in  every  total  order  consistent 
with  precedes(d].  In  other  words  every  serial  history  equivalent  to  permaneni(h).  with  the 
activities  in  an  order  consistent  with  precedes{h).  must  be  acceptable. 

For  example,  the  following  history  n  is  atomic,  but  not  dynamic  atomic; 

<member(3),x,a> 

<msert(3),x,b> 

<ok,x,b> 

<false,x,a> 

<member(3),x,c> 

<commit,x,b> 

<true,x,c> 

<commif,x,a> 

<commit,x,c> 

Permanent(h).  which  is  the  same  as  h.  is  equivalent  to  the  following  acceptable  serial  history: 

<member{3),x,a> 

<false,x,a> 

<commit,x,a> 

<insert{3),x,b> 

<ok,x,b> 

<commit,x,b> 

<member(3),x,c> 

<true,x,c> 

<commit.x,c> 

and  thus  is  serializable  in  the  order  a  followed  by  b  followed  by  c  (written  a  b  c).  However, 
since  precedps(h)  contains  only  the  single  pair  <b,c>,  permanent{h)  must  also  be  serializable 
in  the  orders  b  a  c  and  b  e  a  for  h  to  be  dynamic  atomic.  This  is  not  the  case;  for  example,  the 
serial  history 
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<insert(3)  x,b> 

<ok,x,b> 

<commit,x,b> 

<member(3).x,a> 

<false.x,a> 

<commit  x.a> 

<metnber(3),x,c> 

<tfue  x,c> 

<commit,x,c> 

is  not  acceptable 

As  another  example,  the  history 

<member(2),x,a> 

<insert(3),x,b> 

<ok,x,b> 

<false,x.a> 

<member(3).x,c> 

<commit,x,b> 

<true.x,c> 

<commit,x,a> 

<commit,x,c> 

is  dynamic  atomic.  Precedes{h)  contains  the  single  pair  <0.c>,  and  permanent{h)  is 

serializable  in  the  orders  a  b-c.  b-a  c.  and  b-c  a. 

We  say  that  an  object  x  is  dynamic  atomic  if  every  history  in  x. behavior  is  dynamic  atomic. 

The  following  theorem  justifies  our  claim  that  dynamic  atomicity  is  a  local  atomicity  property: 
Theorem  4-2;  If  every  object  in  a  system  is  dynamic  atomic,  then  every  history  in 
the  system’s  behavior  is  atomic. 

Proof:  Suppose  every  object  in  a  system  is  dynamic  atomic,  and  let  h  be  a  history 
of  the  system.  Precedes{h)  is  a  partial  order,  so  let  T  be  a  total  order  of  the 
activities  in  h  that  is  consistent  with  precedes(h).  By  Lemma  4-1,  precedes(h\x)  C 
precedes{h),  so  T  is  also  consistent  with  precedes{h\x)  for  every  x.  Since  each 
object  is  dynamic  atomic.  petmanent[h\x)  is  serializable  in  every  total  order 
consistent  with  precedes(,h)\  in  particular,  it  is  serializable  in  the  order  T.  By 
Lemmas  3  3  and  3-2,  permanent{h)  is  serializable  in  the  order  T.  Thus,  h  is  atomic. 


4.1.2  Optimality 

Dynamic  atomicity  is  optimal,  there  is  no  other  local  atomicity  property  that  is  strictly  more 
permissive  The  paragraphs  below  state  this  result  precisely  and  provide  a  proof.  We  caution 
the  reader,  however,  that  "optimal”  does  not  mean  "best."  As  we  will  see  in  Section  4.2, 
there  are  other  local  atomicity  properties  that  are  also  optimal,  yet  are  different:  Each  allows 
specifications  not  allowed  by  the  others.  Also,  the  optimality  of  a  local  atomicity  property 
depends  on  the  events  in  the  underlying  model:  a  property  that  is  optimal  in  one  model  may 
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be  Siiboiitimal  in  a  nioctvl  with  more  evenho  it  llte  ;u lililiun.il  evcnii,  piuvidt;-  ubu  cts  with  usnlul 
information  about  the  execution  ol  the  system  We  will  see  an  example  ot  this  latter  situation 
in  Section  4  3  With  these  caveats  m  mind  we  now  present  the  theorem 

As  defined  earlier  a  local  atomicity  property  P  is  any  property  P  of  specifications  of  obiects 
such  that  the  following  is  true  If  the  specification  of  every  object  in  a  system  satisfies  P  then 
every  history  in  the  system's  behavior  is  atomic  We  say  that  a  property  P  is  nea/'C'  (or  nwv 
permissive)  than  a  property  O  if  every  specification  that  satisfies  Q  also  satisfies  P  m  other 
words,  if  O  implies  P.  A  property  P  is  strictly  weaker  than  a  property  O  if  P  is  weaker  than  O, 
and  O  is  not  weaker  than  P.  Note  that  if  P  is  strictly  weaker  than  O  then  there  exists  some 
specification  that  satisfies  P  and  does  not  satisfy  O  If  we  equate  the  level  of  concurrency 
permitted  by  a  property  with  the  behaviors  permitted  by  the  property  for  a  given  serial 
specification,  then  if  P  is  strictly  weaker  than  O.  P  permits  more  concurrency  than  O 

We  say  that  a  local  atomicity  property  P  is  optimal  if  no  local  alomicity  property  is  strictly 
weaker  than  P  The  following  theorem  shows  that  dynamic  atomicity  is  optimal: 

Theorem  4-3:  For  systems  using  the  events  described  in  this  section,  dynamic 
atomicity  is  optimal. 

Proof:  The  proof  proceeds  by  contradiction:  Suppose  dynamic  atomicity  is  not 
optimal  Then  there  exists  a  local  atomicity  property  P  that  is  strictly  weaker  than 
dynamic  atomicity.  We  will  exhibit  a  system  composed  ol  objects  satisfying  P,  and 
show  that  there  is  a  non  atomic  history  of  that  system,  thus  contradicting  the  claim 
that  P  is  a  local  atomicity  property. 

Since  P  is  more  permissive  than  dynamic  atomicity,  there  must  be  a  specification 
Sj  of  an  object  x  such  that  satisfies  P but  x  is  not  dynamic  atomic.  In  particular, 
there  must  be  at  least  one  history  in  x. behavior  that  is  not  dynamic  atomic;  that 
is,  such  that  permanent(h^)  is  not  serializable  in  at  least  one  total  order  T 
consistent  with  precedes(hj.  We  will  construct  an  object  y  whose  specification 
contains  a  history  involving  the  committed  activities  in  h^.  Now,  consider  a 
system  containing  x,  y,  and  all  the  activities  in  h^.  We  will  choose  h^  so  that  is 
serializable  only  in  tire  order  T,  and  there  is  a  history  h  of  this  system  such  that 
h(x  =  and  h{y  =  h^.  Since  permanent{h^)  is  only  serializable  in  the  order  7,  and 
permanent{h^)  is  not  serializable  in  that  order,  it  follows  from  Lemma  3  2  that 
permanent{h)  is  not  serializable.  Thus,  h  is  not  atomic. 

Construction  ot  y: 

The  construction  of  y  is  as  follows:  Lef  y  have  a  single  operation  called  increment. 

Y  is  intended  to  behave  as  a  counter;  Its  state  is  initially  zero,  and  each  invocation 
of  the  increment  operation  increments  the  state  of  y  and  returns  the  resulting 
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value  A  state  machine  describing  the  serial  specification  of  y  appears  m  Figure 
4-1. 

States:  integers  initially  0 

T ransitions  {y:<increment.i>:  i  is  an  integer) 

N(s.y:<increment,i>): 
when  i  =  s  +  1 
changes s to S4  1 

Figure  4-1  iSerial  specification  of  a  counter  object  y. 


The  operation  sequences  in  y. serial  have  the  following  form: 

y:<increment,1> 

y:<increment,2> 

y:<increment,n> 

Let  y  behavior  be  the  largest  set  of  histories  such  that  y  is  dynamic  atomic;  i.e.,  let 
y  behavior  contain  all  dynamic  atomic  histories  h  such  that  h  =  h|y.  Since  P  is 
weaker  than  dynamic  atomicity,  satisfies  P. 

Choice  of  h^: 

Now.  let  a  7,  a2 . an  be  the  committed  activities  in  h^  in  the  order  T,  and  let  h^  be 

the  following  serial  history  in  y. behavior: 

<increment,y,a1> 

<1.y.a1> 

<commit.y,a1> 

<increment,y,a2> 

<2.y.a2> 

<commit,y,a2> 

<increment,y,an> 

<n.y,an> 

<commit,y.an> 

Note  that  h^  is  serializable  only  in  the  order  T. 

Construction  of  h: 

It  now  suffices  to  show  that  there  exists  a  history  h  such  that  h|x  =  and  h|y  s 

h  .  We  note  several  facts  about  h  and  h  : 
r  »  y 

1.  T  is  consistent  with  precedes{h^). 

2.  is  serial,  and  activities  appear  in  the  order  T. 


3  ^  IS  consistent  with  (.>tfcvdfi,(h^). 

4.  commiiied{h^)  =  commilted{h^). 

5.  aborted(h^)  =  0. 

Now  consider  the  lollov^ing  algorithm,  which  we  will  show  "merges"  and  h  to 

get  a  history  h  satisfying  our  requirements: 
s  :  =  A 
sx  :  =  h 

X 

sy  .  =  h 

y 

while  committed(sx)  ^  0  do 

let  sf .  s2,  and  a  be  such  that  sx  =  si‘<commi;.x.a>’s2, 
and  committed{s1)  =  0 
s  :  =  s  •  sJ 
sx  :=  s2 
if  syja  *■  A  then 

let  s3  and  s4  be  such  that  sy  =  s3’<commit.v.a'>'s4 
s  :  =  s  •  s3  •  <commit,y,a> 
sy : =  s4 

end 

s  :  =  s  •  <commit,x,a'> 

end 

s  :  *  s  •  sx  •  sy 
let  h  =  s 

It  is  clear  that  the  algorithm  terminates,  since  each  iteration  of  the  loop  shortens 
sx.  In  addition,  it  is  obvious  that  the  final  value  of  n  contains  thj  initial  values  of 
and  as  subsequences,  as  desired  It  remains  to  be  shown  that  the  event 
sequence  h  is  a  history,  that  is,  that  it  is  well  formed  This  we  do  below. 

Well-formedness  of  h: 

We  repeat  here  the  conditions  on  v/ell  formed  sequences  from  Chapter  2; 

■  An  activity  must  wait  until  one  invocation  terminates  before  invoking 
another  operation.  More  precisely,  let  op  evenis(h)  be  the  subsequence  of 
h  consisting  of  all  invocation  and  termination  events;  then  op  events{h\a) 
must  consist  of  an  alternating  sequence  of  invocation  and  termination 
events,  beginning  with  an  invocation  event.  In  addition,  an  invocation 
event  and  the  immediately  succeeding  termination  event  must  involve  the 
same  object. 

-  No  activity  both  commits  and  aborts  in  h  (at  the  same  or  different  objects); 
i.e.,  commlt{h)  n  abort(h)  =  0, 

•  An  activity  cannot  commit  if  it  is  waiting  for  an  invocation  to  terminate,  and 
an  activity  cannot  invoke  any  operations  after  it  commits  More  precisely,  if 
a  €  commiticd(h).  then  h\a  consists  of  an  alternating  sequence  of 


invocation  and  termination  events,  ending  in  a  termination  event,  followed 
by  some  number  of  commit  events. 

The  second  condition  follows  from  the  fact  that  conumtlvdih)  =  commilled{h^)  U 
commitied{h  )  and  aboited(h)  -  aborted{h  )  U  aborted(h  ).  and  from  the 
previously  slated  facts  about  and  h^. 

We  argue  the  first  condition  as  follows:  If  b  ^  committed{h)  then  bjb  =  h^\b,  and 
the  first  condition  follows  from  well  formedness  of  h^.  Suppose  b  €  committed(h). 
and  suppose  that  the  first  condition  does  not  hold  for  h\b.  we  will  derive  a 
contradiction.  Note  that  if  an  invocation  event  is  in  the  subsequence  s3  moved 
from  sy  to  s.  then  the  corresponding  termination  event  immediately  follows  it  in  s3, 
and  hence  in  h. 

Let  hi  be  the  longest  prefix  of  /)|b  such  that  hi  is  an  alternating  sequence  of 
invocation  and  termination  events,  beginning  with  an  invocation  event.  Since  the 
first  condition  does  not  hold  for  h\b,  h  is  longer  than  hi.  We  claim  that  hi  ends  in 
an  invocation  event  from  h^: 

■  h  1  cannot  end  in  an  invocation  event  from  h  ,  since  the  corresponding 
termination  event  immediately  follows  it  in  h,  implying  that  hi  is  not  the 
longest  prefix  of  alternating  invocation  and  termination  events. 

•  hi  cannot  end  in  a  termination  event  from  h^,  since  the  next  event  in  h\b 
would  then  have  to  be  a  termination  event:  this  second  termination  event 
cannot  come  from  h  ,  since  it  immediately  follows  its  corresponding 
invocation  event,  and  it  cannot  come  from  h^,  since  otherwise  h^\b  would 
contain  two  adjacent  termination  events. 

-  hi  cannot  end  in  a  termination  event  from  h^:  If  it  did.  the  next  event  in  h\b 
would  have  to  be  a  termination  event,  and  would  have  to  come  from  the 
next  to-last  event  In  hi  would  have  to  be  the  invocation  event  from  h^,  and 
the  event  preceding  it  would  have  to  be  an  invocation  event  from 
contradicting  the  assumption  that  ht  is  an  alternating  sequence. 

Since  hi  ends  in  an  invocation  event  from  h^,  the  next  event  in  h\b  must  be  an 
invocation  event  from  h^. 

Now  consider  the  iteration  of  the  main  loop  during  which  the  events  for  b  in  h  are 
moved  in  s3  from  sy  to  s.  s  already  contains  h  7  as  a  subsequence  before  s3  is 
appended  to  s,  and  s2  contains  a  termination  event  for  b.  Let  a  be  the  activity 
whose  commit  event  is  moved  from  sx  to  s  during  that  iteration.  Since  s2  contains 
a  termination  event  for  b.  a  termination  event  lor  b  follows  a  commit  event  for  a  in 
h  so  <a.b>  €  precedes{h  ).  But  events  for  b  at  y  appear  in  s3,  and  so  appear  in  h 

Mm  y 

before  the  commit  event  for  a;  by  the  construction  of  b^,  <b.a>  €  precedes{h^). 
This  is  a  contradiction,  since  T  is  consistent  with  precedes{h^)  and  precedes{h^). 
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Thus,  the  first  condition  holds  lor  /)|<) 

Now  consider  the  third  condition.  Suppose  a  €  romntitred(h)  By  the  first 

condition,  op  ei'ents(h|a)  consists  of  an  alternating  sequence  of  invocation  and 

termination  events;  since  h  and  h  are  well  formed,  it  suffices  to  show  that  no 

*  y 

events  involving  a  except  commit  events  occur  in  h  after  the  first  commit  event  for 
a.  As  shown  above,  when  the  commit  event  for  a  at  y  is  moved  to  s.  only  commit 
events  remain  in  sx  for  a.  When  the  first  commit  event  for  a  at  x  is  moved  to  s, 
either  no  events  remain  for  the  activity  in  sy,  or  the  events  for  the  activity  in  sy  are 
rnoved  to  s,  on  the  same  iteration  of  the  main  loop,  before  the  commit  event  from 
sx  is  moved  to  s. 

Thus,  h  is  well-formed.  Since  permanent{hj  is  not  serializable  in  the  order  T,  and 
permaneni{h^)  is  serializable  only  in  the  order  7,  h  is  not  atomic.  This  is  the 
desired  contradiction,  showing  that  dynamic  atomicity  is  optimal. 

The  locking  protocols  of  [Bernstein  et  al.  81]  and  [Korih  81a]  are  suboptimal:  while  sufficient 
to  ensure  atomicity  (given  their  assumptions  about  the  underlying  recovery  mechanism),  they 
achieve  strictly  less  concurrency  than  permitted  by  dynamic  atomicity.  We  will  illustrate  this 
point  with  detailed  examples  in  Chapter  5. 

4.2  Static  Atomicity 

Protocols  characterized  by  dynamic  atomicity  determine  a  serialization  order  for  activities 
based  on  the  dynamics  of  the  execution  of  activities.  In  contrast,  timestamp  protocols  (see, 
e  g.,  [Reed  78])  determine  a  serialization  order  for  activities  statically,  based  on  timestamps 
chosen  when  activities  start.  Our  second  local  atomicity  property  characterizes  the  behavior 
of  protocols  which  are  static  in  this  sense.  We  call  this  properly  static  atomicity. 

The  remainder  of  this  section  is  divided  into  three  subsections.  In  the  first,  we  define  static 
atomicity  and  prove  that  it  is  a  local  atomicity  property.  Then,  in  the  second,  we  show  that 
static  atomicity  is  optimal  Finally,  in  the  third,  we  compare  static  and  dynamic  atomicity. 

4.2.1  Definition  of  Static  Atomicity 

Static  atomic  objects  ensure  that  activities  are  serializable  in  a  pre  determined  order.  We 
model  this  behavior  as  follows:  Let  ACT  be  the  set  of  all  activities,  and  let  TS  be  a  fixed  total 
4  order  on  ACT.  Let  h  be  a  history  containing  initiation,  invocation,  termination,  commit,  and 

abort  events  We  say  that  h  is  static  atomic  if  permanent(h)  is  serializable  in  the  order  TS 

For  example  suppose  x  is  a  set  object  as  before  Suppose  that  a  and  b  are  activities,  and  that 


TS  orders  b  before  <i  Then  Ihe  following  hisioiy  h  is  atomic,  but  not  static  atomic: 

<membef(3).x.a> 

<false.x.a> 

<commit.x.a> 

<insert(3),x,b> 

<ok,x.b> 

<commit,x,b> 

Permanent{h)  is  a  serial  history  and  is  serializable  in  the  order  a  b  However,  permanent{h)  is 
not  serializable  in  the  order  b  a.  which  is  the  order  specified  by  TS. 

As  another  example,  the  history 

<inserl(3).x,a> 

<ok,x.a> 

<commit.x,a> 

<member(3),x,b> 

<false,x.b> 

<commit,x,b> 

is  static  atomic:  Permaneni(h)  is  serializable  in  the  order  TS. 

We  say  that  an  object  is  static  atomic  if  every  history  permitted  by  the  object  s  behavioral 
specification  is  static  atomic.  The  following  theorem  verifies  that  static  atomicity  is  a  local 
atomicity  property: 

Theorem  4-4:  If  every  object  in  a  system  is  static  atomic,  then  every  history  in  the 
system’s  behavior  is  atomic. 

Proof:  Suppose  that  every  object  in  a  system  is  static  atomic,  and  let  h  be  a  history 
of  the  system.  By  the  definition  of  static  atomicity,  permanent{h\x)  is  serializable  in 
the  order  TS.  By  Lemmas  3-3  and  3-2,  permanent{h)  is  aiso  serializable  in  the 
order  TS,  so  h  is  atomic. 

4.2.2  Optimality 

Static  atomicity,  like  dynamic  atomicity,  is  optimal.  The  paragraphs  below  provide  a  precise 
proof  of  this  result.  We  begin  with  some  definitions,  and  then  prove  the  theorem. 

If  h  is  a  history,  define  the  relation  commit  order(h)  on  activities  to  contain  alt  pairs  <a.b>  such 
that  a.b  €  committed(h)  and  the  first  commit  event  for  a  in  h  occurs  before  the  first  commit 
event  for  b  in  h.  Note  that  commit ■order{h)  is  a  partial  order  on  activities,  and  that  it  totally 
orders  committed{h). 

Theorem  4-5:  For  systems  using  the  events  described  in  this  section,  static 
atomicity  is  optimal. 

Proof:  The  proof  proceeds  by  contradiction,  along  the  lines  of  the  proof  of 
Theorem  4  3.  Suppose  P  is  a  local  atomicity  property  that  is  strictly  weaker  than 
static  atomicity  We  will  exhibit  a  system  composed  of  objects  satisfying  P,  and 
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sliow  that  there  is  a  non  atoinic  history  of  that  system,  thus  contradicting  tire  claim 
that  P  IS  a  local  atomicity  property. 

Since  P  IS  more  permissive  than  static  atomicity,  there  most  be  a  specification 

of  an  obiect  x  such  that  satisfies  Pbut  x  is  not  static  atomic  In  particular,  there 

must  be  at  least  one  history  in  x  behavior  that  is  not  static  atomic,  that  is  such 

that  permanent(hj  is  not  serializable  in  the  order  TS  We  will  construct  an  object  y 

whose  specification  contains  a  history  involving  the  committed  activities  m  h^. 

Now.  consider  a  system  containing  x,  y.  and  all  the  activities  in  h^.  As  m  the  proof 

of  Theorem  4  3,  will  be  chosen  so  that  it  is  serializable  only  in  the  order  TS.  and 

there  is  a  history  h  of  this  system  such  that  h|x  =  and  h|y  =  h^.  Since 

permanenith  }  is  only  serializable  in  the  order  TS,  and  permanent{h  )  is  not 
y  ^ 

serializable  in  that  order,  it  follows  from  Lemma  3-2  that  permanent(h)  is  not 
serializable.  Thus,  h  is  not  atomic. 

Construction  of  y; 

The  serial  specification  of  y  is  the  same  as  in  the  proof  of  Theorem  4-3,  and  is 
described  by  the  machine  in  Figure  4-1.  Let  y. behavior  be  the  largest  set  such  that 
y  IS  static  atomic  Notice  that  while  the  serial  specification  of  y  is  the  same  as  in 
the  proof  of  Theorem  4-3,  the  behavioral  specification  is  different.  Since  P  is 
weaker  than  static  atomicity,  satisfies  P. 

Choice  of  h^. 

Now,  let  at,  a2 .  an  be  the  activities  in  committed[h^)  in  the  order 

commit  orderih).  Let  order:  {at . an)  — *  (1,2,...,n]  map  the  ai  to  the  integers 

between  1  and  n  such  that  order(ai)<order(aj)  if  and  only  if  TS  orders  ai  before  aj. 
Let  be  the  following  seiial  history  m  y  behavior: 

<increment.y,a1> 

<order(a1),y,a1> 

<commit,y,a1> 

<increment,y,a2> 

<order(a2),y,a2> 

<commit.y,a2> 

<increment,y,an> 

<order(an),y,an> 

<commit.y,an> 

Note  that  h^  is  serializable  only  in  the  order  TS, 


Existence  of  h. 
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By  the  same  arguments  as  in  the  proof  of  Theorem  4  3.  there  exists  a  history  h 
such  that  h|x  =  and  h|y  =  h^.  This  gives  the  desired  contradiction. 

4.2.3  Discussion 

Dynamic  atomicity  and  static  atomicity  are  different  each  permits  operations  to  be 
interleaved  in  ways  that  the  other  does  not  This  implies  that  optimal  does  not  mean  "best." 
but  rather  that  nothing  else  is  strictly  better. 

Which  of  these  two  local  atomicity  properties  is  better  for  a  given  application  will  depend  on 
the  patterns  of  operations  invoked  by  activities.  For  example,  dynamic  atomicity  works  poorly 
for  long  read  only  activities  such  as  audits.  If  dynamic  atomicity  is  implemented  using  a 
locking  protocol,  a  read  only  activity,  once  it  has  a  lock  on  an  object,  will  cause  other 
activities  that  need  conflicting  locks  to  wait.  Because  of  the  need  to  wait  for  locks,  long 
read  only  activities  can  be  quite  prone  to  deadlock.  Static  atomicity,  however,  works 
reasonably  well  for  long  read  only  activities.  In  the  implementation  proposed  by  Reed  [Reed 
73].  read  only  activities  are  never  forced  to  abort  (the  analog  of  deadlock  in  a  looking  system), 
and  are  rarely  delayed  by  other  activities.  On  the  other  hand,  static  atomicity  works  poorly  for 
update  activities  with  old  timestamps  For  example,  in  the  implementation  proposed  by  Reed, 
if  an  activity  attempts  to  write  an  object  after  another  activity  with  a  later  timestamp  has 
already  read  the  object,  the  former  activity  must  be  aborted.  Using  dynamic  atomicity,  the 
v/riter  might  be  delayed  until  the  reader  committed,  but  would  then  be  able  to  proceed. 

4.3  Hybrid  Atomicity 

Our  final  local  atomicity  property,  v/hich  we  call  hybrid  atomiciiy,  characterizes  the  behavior 
of  protocols  that  exhibit  some  of  the  characteristics  of  dynamic  atomic  protocols  and  some  of 
the  characteristics  of  static  atomic  protocols.  Examples  of  such  protocols  include  the  mixed 
methods  of  (Bernstein  &  Goodman  81,  Section  5  3.2]  and  the  multi  version  scheme  proposed 
in  [DuBourdieu  82]  and  formally  analyzed  in  [Bernstein  &  Goodman  83). 

Hybrid  atomicity  is  based  on  two  ideas  First,  we  partition  activities  into  two  classes:  read¬ 
only  activities,  and  update  activities  Intuitively,  a  read  only  activity  is  one  that  does  not 
invoke  any  operations  that  change  the  state  of  an  object  Formally  if  the  serial  specification 
of  an  object  is  described  by  a  state  machine  M.  then  an  operation  O  on  the  object  is  read  only 
if  Nj^(S.O)  =  S  for  ail  states  S  in  which  O  is  defined  An  activity  is  read  only  if  every  operation 
executed  by  the  activity  is  read  only.  All  other  activities  are  considered  to  be  update  activities 

As  in  Reed  s  implementation  of  static  atomicity  timestamps  for  read  only  activities  ore  chosen 


when  tliey  begin  execution  Timestamps  for  update  activities,  however,  are  chosen 
dynamically  as  they  coinmit  The  system  ensures  that  the  timestamp  order  on  updates  is 
consistent  with  the  p>eccdcs  order;  objects  can  use  this  property  to  ensure  that  updates  are 
serializable  m  timestamp  order. 

When  a  read  only  activity  with  timestamp  t  invokes  an  operation  on  an  object,  the  answer  to 
Its  query  is  computed  by  including  the  effects  of  all  operations  executed  by  committed  update 
activities  with  timestamps  less  than  t  The  system  also  ensures  that  update  activities  that 
commit  later  choose  a  timestamp  greater  than  t.  ensuring  that  the  results  returned  to  the 
read  only  activity  are  not  invalidated  by  an  update  that  commits  later. 

The  remainder  of  this  section  is  divided  into  three  subsections  In  the  first,  we  describe  the 
additional  events  needed  to  define  hybrid  atomicity.  In  the  second  we  define  hybrid  atomicity 
and  prove  that  it  is  a  local  atomicity  property  We  also  claim  that  hybrid  atomicity  Is  optimal. 
Finally,  in  the  third,  we  compare  hybrid  atomicity  to  static  atomicity  and  dynamic  atomicity. 


4.3.1  Additional  Events 

To  define  hybrid  atomicity  precisely,  we  need  to  introduce  some  new  events  that  describe  the 
timestamps  chosen  by  activities.  In  addition,  we  must  partition  the  set  of  activities  into  two 
subsets:  the  updates  (written  a,  b.  and  c),  and  the  read  only  activities  (written  r  and  s) 
Timestamps  for  updates  are  chosen  when  they  commit,  and  an  object  learns  of  an  update’s 
timestamp  when  the  update  commits  at  the  object.  We  write  the  event  corresponding  to  the 
commitment  of  an  update  a  at  object  x  with  timestamp  f  as  <commit(t).x.a>  Timestamps  for 
read  only  activities  are  chosen  when  they  start,  and  an  object  learns  of  a  read  only  activity's 
timestamps  when  the  activity  invokes  an  operation  on  the  object.  We  model  this  by  including 
initiation  events:  Before  invoking  an  operation  on  an  object,  a  read  only  activity  must  initiate 
at  the  object  to  let  the  object  know  its  timestamp  We  write  the  event  corresponding  to  the 
initiation  of  activity  r  at  object  x  with  timestamp  t  as  <initiate(t).x.r>.  We  use  the  term 
timestamp  events  to  denote  the  set  of  all  commit  events  for  updates  and  all  initiation  events 
for  read  only  activities. 

We  assume  that  timestamps  are  taken  from  some  countable,  totally  ordered  set:  in  our 
examples  we  will  use  natural  numbers. 

In  addition  to  the  well-formedness  constraints  on  event  sequences  stated  in  Chapter  2.  we 
have  the  following  constraints: 

•  A  read  only  activity  must  initiate  at  an  object  before  invoking  any  operations  at 
the  object:  i  e..  for  every  read  only  activity  r  and  every  object  x,  h|r|x  begins  with 
an  initiation  event. 
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Any  two  tiniestainp  events  (of  dislmcl  activities  liave  distinct  timestamps 
Any  two  timestamp  events  for  the  same  activity  have  the  same  timestamp 

For  example,  the  following  sequence  is  well  formed: 

<inseft(3).x,a> 

<ok,x,a> 

<commif{2),x,a> 

<initiate(1),x,r> 

<membef(3).x,r> 

<false.x.r> 

<Commit.x,r> 

The  following  sequence  h,  however,  is  not: 

<insert(3),x,a> 

<ok,x,a> 

<commit(2),x,a> 

<member(3),x,b> 

<true,x,b> 

<commit(1  ),x,b> 

<initiate(2),x.r> 

since  r  and  a  use  the  same  timestamp,  violating  the  uniqueness  property  of  timestamps 

We  extend  the  definition  of  opseq  to  histories  including  timestamp  events  by  having  opseq 
throw  away  timestamp  events  in  addition  to  completion  events  Acceptability,  serialirability, 
and  atomicity  for  histones  are  then  defined  as  before  in  terms  of  opseq. 

4.3.2  Definition  of  Hybrid  Atomicity 

Let  h  be  a  history.  We  say  that  h  is  hybrid  atomic  if  permanent{h)  is  serializable  in  timestamp 
order 

For  example,  let  x  be  a  set  object  as  before,  then  the  following  history  h  is  atomic: 

<insert(3),x.a> 

<ok.x,a> 

<insert(4),x.b> 

<ok,x.b> 

<commit(l),x.a> 

<commit(3),x,b> 

<initiate(2),x,r> 

<member(3).x,r> 

<true.x,r> 

<member(4),x,r> 

<true,x,r> 

<commit,x.r> 

since  it  IS  serializable  in  the  order  a  b  r  However,  it  is  not  hybrid  atomic,  for  the  following 
reason  Pcrmanent{h)  in  timestamp  order  is  the  history 
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<insert(3).x  a> 

<ok.x  a> 

<commit(l).x,a> 

<initiate{2),x,r> 

<member(3),x,r> 

<true.x,r> 

<member(4),x,r> 

<true,x,r> 

<commit.x.r> 

<insert(4),x,b> 

<ok,x,b> 

<commit(3).x.b> 

which  IS  not  an  acceptable  serial  history. 

As  another  example,  the  history 

<insert(3),x,a> 

<ok,x,a> 

<insert(4),x,b> 

<ok,x.b> 

<commit(1),x,a> 

<commit(3),x,b> 

<inifiate(2),x,r> 

<member(3),x,r> 

<true,x,r> 

<member(4),x,r> 

<false,x,r> 

<commjt,x,r> 

IS  hybrid  atomic. 

We  say  that  an  object  is  hybrid  atomic  if  every  history  permitted  by  the  object's  behavioral 

specification  is  hybrid  atomic.  The  following  theorem  verifies  that  hybrid  atomicity  is  a  local 

atomicity  property: 

Theorem  4-6:  If  every  obiect  in  a  system  is  hybrid  atomic,  then  every  history  of 
the  system  is  atomic. 

The  proof  IS  identical  to  that  for  static  atomicity. 

Hybrid  atomicity  is  optimal:  the  proof  again  is  by  contradiction 


4.3.3  Discussion 

At  first  glance  hybrid  atomicity  might  not  seem  very  different  from  static  atomicity:  both  work 
by  establishing  a  single  global  ordering  on  activities  and  ensuring  that  activities  are 
serializable  in  that  order.  Static  atomicity  uses  a  pre  determined  order,  chosen  before 
activities  begin  executing.  Hybrid  atomicity,  in  contrast,  uses  an  order  determined  by  the 
order  in  which  updates  commit.  This  difference  is  substantial  it  raises  a  number  of 
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interesting  implementation  issues,  and  results  in  some  useful  properties 


One  simple  way  to  implement  hybrid  atomicity  is  to  use  dynamic  atomicity  for  update 
activities,  generating  timestamps  for  them  so  that  the  timestamp  order  on  updates  is 
consistent  with  the  precedes  order,  and  to  compute  the  results  of  an  operation  invoked  by  a 
read  only  activity  with  timestamp  f  by  including  the  effects  of  all  committed  updates  with 
timestamps  less  than  i.  (See.  e  g  .  [DuBourdieu  82.  Bernstein  S  Goodman  83]  for  a  detailed 
description  of  this  approach  for  simple  objects  with  read  and  write  operations  )  This  simple 
implementation,  like  implementations  of  static  atomicity,  permits  read  only  activities  to  run 
without  interfering  with  update  activities:  by  using  dynamic  atomicity  for  updates,  however, 
the  problems  of  static  atomicity  are  avoided. 

More  complex  implementations  of  hybrid  atomicity  can  allow  more  concurrency  among 
update  activities  than  is  permitted  by  dynamic  atomicity  Consider,  for  example,  a  first  in-first 
out  queue  obiect  z  with  a  serial  specification  as  described  by  the  machine  in  Figure  3-2. 
Hybrid  atomicity  allows  activities  to  enqueue  items  in  parallel  as  is  Illustrated  by  the  following 
hybrid  atomic  history: 

<enqueue(1),z,a> 

<enqueue(2),z,b> 

<ok,z,a> 

<ok.z,b> 

<commit{3).z,b> 

<commit{5),z,a> 

<dequeue,z.c> 

<2.z,c> 

<dequeue,z,c> 

<1,z,c> 

<commit(17),z,c> 

Dynamic  atomicity  allows  activities  to  enqueue  items  in  parallel,  but  the  items  enqueued 
cannot  be  dequeued  by  another  activity  Consider  the  following  history  h: 

<enqueue(l),z,a> 

<enqueue(2).z,b> 

<ok.z,a> 

<ok,z.b> 

<commit,z,b> 

<commit.z,a> 

<dequeue.z,c> 

<?.z.c> 

<commit.z.c> 

If  c  dequeues  1  in  place  of  the  then  h  is  not  serializable  in  the  order  b  a  c;  if  c  dequeues 
2.  then  h  is  not  serializable  in  the  order  a  b  e  Since  precedcs{h)  contains  only  the  pairs  <a,c> 
and  <fc.c>,  h  IS  not  dynamic  atomic,  regardless  of  which  item  is  dequeued  by  c.  (In  Chapter  5, 
we  will  discuss  this  problem  with  dynamic  atomicity  in  more  detail,  and  will  explain  how  to 
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Hybrid  atomicity  can  allow  more  concurrency  than  dynamic  atnnucity  herause  the  Objects 
have  more  information  namely  the  timestamps  assigned  to  update  activities  as  they  commit 
This  does  not  contradict  our  optimality  results,  but  rather  serves  to  emphasize  their 
dependence  on  the  mlormation  available  to  objects  (Cl  the  work  in  [Kung  ft  Papadinutnou 
79]  on  the  "optimality”  of  concurrency  control  protocols,  and  the  dependence  of  "optimality  " 
on  the  amount  of  information  available  to  the  protocols.) 

Lamport  (Lamport  76]  suggested  that  atomicity  is  too  strong  a  requirement  because  it  permits 
too  little  concurrency,  and  presented  the  example  of  a  banking  system  to  support  his  claim 
The  system  contains  transfer  activities  (which  move  money  between  two  accounts)  and  audit 
activities  (which  print  out  the  current  balances  of  all  accounts)  Lamport  noted  the 
performance  problems  of  locking  implementations,  and  suggested  that  the  solution  to  these 
problems  is  to  allow  non  atomic  executions  He  defined  a  correctness  property,  namely  that 
the  view  of  the  database  seen  by  an  audit  must  be  consistent  and  described  an 
implementation  that  guarantees  this  property  while  permitting  more  concurrency  than  a 
locking  implementation  of  atomicity.  His  correctness  property  does  not  ensure,  however  that 
the  view  seen  by  an  audit  bears  any  relation  to  the  actual  state  of  the  database  In  addition, 
audits  under  his  implementation  still  interfere  with  some  updates.  The  implementations  of 
hybrid  atomicity  discussed  above  solve  the  problem  addressed  by  Lamport,  namely  the 
performance  problems  with  read- only  acfrWfies  under  dynamic  atomicity.  In  contrast  to 
Lamport's  solution,  hybrid  atomicity  ensures  atomicity;  this  means  that  the  view  seen  by  an 
audit  can  be  related  to  the  updates  performed  by  transfers  and  to  the  views  sr'en  by  other 
audits.  In  addition,  hybrid  atomicity  can  be  implemented  so  that  audits  do  not  interfere  with 
any  updates,  and  the  techniques  can  be  applied  easily  to  other  situations  involving  read  only 
activities. 

Our  primary  motivation  tor  developing  hybrid  atomicity  was  to  solve  the  problems  of  dynamic 
atomicity  with  long  read  only  activities.  In  addition,  hybrid  atomicity  permits  more 
concurrency  among  update  activities  than  does  dynamic  atomicity.  For  example,  hybrid 
atomicity  permits  a  FIFO  queue  that  allows  concurrent  use  of  eno  operations  Hybrid 
atomicity  also  appears  useful  for  replication;  Herlihy  [Herlihy  84)  has  developed  novel 
replication  techniques,  based  on  hybrid  atomicity,  for  user  defined  objects  Hybrid  atomicity 
permits  greater  freedom  in  choosing  quorums  for  operations  than  dynamic  atomicity, 
providing  the  potential  for  increased  availability. 
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4.4  Remarks 

In  this  section  we  discuss  a  number  of  issues  related  to  the  material  presented  earlier  The 
section  IS  divided  into  three  subsections  In  the  first,  we  return  to  the  issue  of  type  specific 
concurrency  control  discussed  in  Chapter  1.  In  the  second,  we  discuss  the  meaning  of  the 
term  "atomic  type."  and  explain  how  the  local  atomicity  properties  discussed  above  serve  to 
classify  different  kinds  of  atomic  types  Finally,  in  the  third,  we  discuss  the  structure  of 
specifications  of  obiects. 


4.4.1  Type-specific  Concurrency  Control 

Let  us  consider  the  example  of  a  semiqueue  object  discussed  earlier  The  serial  specification 
of  a  semiqueue  object  y  was  given  in  Figure  2  3.  Consider  the  following  history  h: 

<enq(1),y.a> 

<enq{2),y,b> 

<ok,y,b> 

<ok,y,a> 

<enq(3),y,a> 

<ok,y,a> 

<enq(4),y,b> 

<ok,y,b> 

<commit,y,a> 

<commit,y,b> 

<deq,y,c> 

<3,y,c> 

<commit,y,c> 

Permanent{h)  is  the  same  as  h,  and  precedes{h)  contains  the  pairs  <a,c>  and  <b,c>.  The 
reader  may  check  that  permanent{h)  is  serializable  in  the  orders  a  b  c  and  b  a-c.  and  thus 
that  h  is  dynamic  atomic. 

Protocols  based  on  a  free  interpretation  of  the  operations  (as  used  in  [Papadimitriou  79]) 
cannot  achieve  this  kind  of  concurrency:  each  operation  is  assumed  to  update  the  object's 
state,  implying  that  activities  cannot  access  an  object  concurrently.  For  example,  two-phase 
locking  using  exclusive  locks  is  shown  in  (Kung  &  Papadimitriou  79]  to  be  optimal,  given  that 
no  information  is  available  about  the  semantics  of  operations.  The  example  above,  and 
others  throughout  this  dissertation,  illustrate  how  a  specification  of  the  acceptable  serial 
behavior  of  objects  can  be  used  to  achieve  greater  concurrency. 


4.4.2  Atomic  Types 

I  As  discussed  in  the  introduction,  a  data  type  consists  of  a  collection  of  objects  with 

associated  operations  We  extend  properties  of  objects  to  types  as  follows:  We  say  that  a 
type  satisfies  a  properly  P  if  all  of  its  objects  satisfy  P.  For  example,  if  a  type's  objects  are  all 
dynamic  atomic,  wr?  say  that  the  type  is  dynamic  atomic 


Each  of  the  three  local  atonrrcity  properties  discussed  in  this  chapter  delines  a  class  of 
''atomic"  types  The  types  within  a  single  class  are  "compatible."  in  the  sense  that  as  long  as 
all  types  in  a  system  belong  to  a  single  class,  activities  are  guaranteed  to  be  atomic  Types  in 
different  classes  are  not  necessarily  compatible:  for  example,  as  illustrated  m  Chapter  1, 
atomicity  is  not  guaranteed  if  dynamic  atomic  and  static  atomic  objects  are  used  together 

Indeed,  a  recent  paper  on  concurrency  control  [Been  et  al  83]  claims  to  "venly"  an 
implementation  of  an  atomic  type  taken  from  (Weihl  &  Liskov  82]  The  type  happens  to  be 
dynamic  atomic.  However,  all  that  is  shown  in  [Been  ef  ai  83]  is  that  every  history  permitted 
by  the  implementation  is  atomic  As  we  illustrated  in  Chapter  1.  if  the  implementation  v^ere 
placed  in  a  system  containing  incompatible  types,  atomicity  could  be  violated  Our  results 
show  that  there  are  many  different  definitions  for  the  term  "atomic  type."  and  that  it  is 
necessary  to  check  that  the  different  types  in  a  system  are  all  compatible. 

4.4.3  Structure  of  Specifications 

We  separated  the  serial  specification  of  an  obi:ct  from  its  behavioral  specification  to  reflect 
the  stages  of  our  informal  design  process  As  the  following  example  illustrates,  this 
separation  also  enhances  the  modularity  of  a  system,  by  reducing  the  amount  of  information 
about  an  object  needed  by  the  programmer  of  an  activity. 

Consider  the  plight  of  the  programmer  of  a  single  activity  who  is  given  a  behavioral 
specification  (and  no  separate  serial  specification)  for  each  object  and  the  assurance  that 
every  system  history  is  atomic.  The  programmer  would  like  to  ignore  the  non  serial  histories 
in  each  object's  specification,  since  atomicity  is  supposed  to  ensure  that  all  histories  are 
"serializable."  Now  consider  the  following  serial  history  in  the  specification  of  an  object  x 
which  is  informally  documented  as  a  set  of  integers: 

<insert(3),x,a> 

<ok,x,a> 

<commit.x.a> 

<member{3),x,b> 

<false.x,b> 

<commit,x.b> 

Without  knowing  the  local  atomicity  property  satisfied  by  x.  the  programmer  will  find  it  difficult 
to  place  a  reasonable  interpretation  on  this  history  If  *  is  static  atomic,  and  TS  orders  b 
before  a.  then  the  history  makes  sense  for  a  set  object,  since  it  is  serializable  m  the  order  TS. 
If.  however,  x  is  dynamic  atomic,  the  history  is  rather  odd:  One  would  expect  b  to  find  3  m  the 
set  after  it  has  been  inserted  by  a  By  separating  the  serial  specification  from  the  behavioral 
specification,  we  avoid  the  need  for  the  programmer  of  an  activity  to  understand  the  details  of 
the  local  atomicity  property  used  by  objects.  Instead,  the  programmer  needs  to  know  only 
that  every  system  history  is  atomic:  he  or  she  can  then  check  that  an  activity  preserves 
consistency  using  only  the  serial  specification  of  each  object. 


Chapter  Five 


Locking 


In  this  chapter  we  look  at  how  two  phase  locking  protocols  can  be  used  to  implement 
dynamic  atomic  obiects  We  begin  in  Section  5  1  by  reviewing  the  locking  protocols  in  the 
literature  [Bernstein  et  al.  ei.Korth  81a],  These  protocols  are  limited  in  several  ways, 
particularly  in  their  inability  to  handle  non  deterministic  operations.  Then,  in  Section  5  2.  we 
describe  a  general  locking  protocol  that  avoids  some,  but  not  all.  of  the  limitations  of  existing 
protocols  Our  description  covers  both  synchronization  and  recovery.  Next,  in  Section  5.3. 
we  verify  that  the  protocol  described  in  Section  5.2  ensures  dynamic  atomicity.  Finally,  in 
Section  5.4,  we  discuss  a  number  of  related  issues. 

5.1  Existing  Protocols 

The  two  phase  locking  protocol  of  [Eswaren  et  at  76]  has  been  extended  in  [Bernstein  el  al. 
81]  and  [Korth  81  a]  to  use  user-specified  information  about  objects  to  increase  concurrency. 
These  extended  protocols  restrict  invocations  to  be  total  and  deterministic;  If  M  is  a  machine 
describing  a  serial  specification,  S^^  is  the  state  domain  of  M,  and  TERM  is  the  set  of 
termination  events,  then  for  every  invocation  event  i  we  can  define  a  total  function  perform  ■. 

X  TERM,  where  perform.(,s)  =  <s'.r>  and  N|^{s, <i,r>)  =  s'.  In  other  words,  for  every 
invocation  i,  and  every  slate  s  of  M,  there  exists  exactly  one  termination  event  r  such  that 
N..(s.</,r>)  *■  ±.  In  contrast,  we  permit  partial  invocations,  for  which  there  may  be  no 
termination  event  in  some  states,  and  non  deterministic  invocations,  for  which  there  may  be 
more  than  one  termination  event  in  some  states.  The  serial  specification  of  the  semiqueue 
object  in  Figure  2  3  illustrates  both  The  deg  invocation  is  partial  (there  are  states  in  v/hich  no 
execution  of  deq  is  defined)  and  non  deterministic  (there  are  states  in  which  more  than  one 
execution  of  deq  is  defined). 

Like  the  read-write  locking  protocol  discussed  in  Chapter  1,  these  extended  protocols 
partition  the  set  of  operations  on  an  object  into  classes,  and  use  a  different  lock  mode  for 
each  class  Classes  are  relatively  coarse-grained:  for  example,  all  operations  with  the  same 
invocation  event  are  in  the  same  class. 

Informally,  we  say  that  a  lock  mode  for  one  class  is  compatible  with  a  lock  mode  for  another 
class  if  all  operations  in  the  first  class  "commute"  with  all  operations  in  the  second  class. 
Two  lock  modes  conflict  if  they  are  not  compatible. 

An  execution  of  an  operation  must  first  acquire  a  lock  in  the  mode  defined  for  its  class  A  lock 
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can  be  acquired  if  no  concurrent  activity  holds  a  conflicting  lock.  Locks  are  released  when 
activities  complete.  If  an  operation  is  unable  to  acquire  its  lock,  it  waits  until  conflicting 
activities  complete. 

The  proof  that  this  extended  protocol  ensures  dynamic  atomicity  is  relatively  simple:  since 
operations  executed  by  concurrent  activities  "commute."  they  can  be  reordered  without 
affecting  their  results  or  the  final  state  By  appropriately  reordering  operations,  we  can  obtain 
a  serial  execution  equivalent  to  any  concurrent  execution  that  obeys  the  locking  rules.  This 
proof  depends,  however,  on  the  requirement  that  operations  be  total  and  deterministic  In  the 
next  two  sections  we  define  and  verify  a  general  locking  protocol  that  permits  partial  and 
non  deterministic  operations.  The  protocols  of  (Bernstein  et  al.  81]  and  (Korth  81a]  are 
spec  al  cases  of  our  protocol  In  our  remarks  at  the  end  of  the  chapter  we  discuss  the 
differences  between  our  protocol  and  the  protocols  of  [Bernstein  et  al  81,  Korth  81  a],  and 
illustrate  how  their  requirements  enable  the  proof  to  be  simplified. 


5.2  A  General  Locking  Protocol 

Like  the  locking  protocols  of  (Eswaren  el  al.  76,  Bernstein  ef  al.  81,  Korth  81a],  our  protocol  is 
based  on  the  notion  of  "commutativity”  of  operations  We  begin  our  description  of  the 
protocol  by  precisely  defining  commutativity. 

5.2.1  Definition  of  Commutativity 

It  is  convenient  to  define  commutativity  quite  generally,  so  that  it  covers  sequences  of 
operations,  not  just  individual  operations.  If  M  is  a  state  machine,  and  T  and  U  are  two 
sequences  of  transitions  of  M,  we  say  that  T  and  U  commute  if,  for  every  state  s  in  which  T 
and  U  are  both  defined,  T{U(s))  =  U(T(s))  and  T(U(s))  *  ±. 

The  obvious  definition  of  commutativity  is  simply  that  T  and  U  commute  if,  for  all  states  s, 
T(LI(s))  =  U(T(s)).  Our  definition  differs  in  two  respects  from  this  simple  definition:  First,  we 
only  care  about  those  states  in  which  T  and  L)  are  both  defined  Second,  we  require  that  the 
state  resulting  from  application  of  both  T  and  U  be  defined  The  simple  definition  permits 
T(U(s))  =  U(T(s))  =  ±.  As  should  be  clear  from  the  proof  in  the  next  section,  the  more 
complex  definition  is  necessary  for  the  protocol  to  work. 

We  illustrate  our  definition  of  commutativity  with  some  examples  taken  from  the  serial 
specification  of  a  set  object  x  in  Figure  2-2.  If  T  =  x:<inser1(i),ok>  and  U  «  x:<insert{j),ok>, 
I  then  T  and  U  commute:  Both  are  defined  in  ail  states,  and  T(U(s))  =  U(T(s))  «  sU{i)U{j). 

On  the  other  hand,  if  V  =  x:<delete(i),ok>.  then  T  and  V  do  not  commute:  T(V(s))  =  sU{i), 
while  V(T(s))  =  s  {i}  LI  and  V  commute,  hov/ever,  as  long  as  i^j. 
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Siipposf  W  =  X  <nK'inbor(i)  W  aiul  V  ilo  not  coniiiuile  V  and  W  aie  botli  tlofined  only 

in  slates  containiny  I  II  s  contains  I,  V(W(s))  =  V(s)  =  s  {i)  However.  W(V(s))  =  W(s  {i))  - 
±,  so  W  and  V  do  not  commute.  On  the  other  hand  W  and  T  commute  If  s  contains  i. 
T(W(s))  =  W(T(s))  =  sU{i)  =  s, 

5.2.2  The  Protocol 

Our  description  of  our  protocol  is  designed  to  emphasize  the  general  strategy  followed  by  the 
protocol,  and  to  highlight  the  diflerences  with  other  locking  protocols  We  do  not  address  m 
this  chapter  the  problem  of  designing  an  efficient  implementation  of  the  protocol  for  a 
particular  object.  An  efficient  implementation  of  this  protocol  for  a  "map"  data  type  can  be 
found  in  the  appendix. 

We  assume  that  the  serial  specification  of  an  object  x  is  given  by  a  state  machine  SERIAL.  We 
let  the  behavioral  specification  of  x  consist  of  all  dynamic  atomic  complete  histories  An 
implementation  of  x  is  described  by  the  state  machine  LOCK  in  Figure  5  1  The  language  of 
the  machine  LOCK  consists  of  a  set  of  event  sequences  involving  x;  in  the  next  section  we  will 
show  that  LOCK  is  correct  in  the  sense  that  every  complete  history  in  L(LOCK)  is  dynamic 
atomic. 

The  definition  of  LOCK  uses  some  new  notation:  ACT  is  the  set  of  all  activities,  INV  is  the  set 
of  all  invocation  events,  and  sequence(S),  where  S  is  a  set,  is  the  set  of  all  sequences  of 
elements  of  S.  Also,  the  expression  m[x-*y),  where  m  is  a  (possibly  partial)  function  from  X  to 
Y.  x€X,  and  y£Y,  denotes  that  function  identical  to  m  except  at  x.  which  it  maps  to  y  Recall 
that  the  symbol  is  used  to  denote  a  partial  function. 

The  machine  LOCK  works  roughly  as  follows;  Recovery  is  accomplished  using  intentions 
lists.  When  a  termination  event  occurs  for  an  activity,  the  operation  (consisting  of  the 
termination  event  and  its  corresponding  invocation  event)  is  appended  to  an  intentions  list  for 
the  activity  When  an  activity  commits,  the  operations  on  its  intentions  list  are  applied  to  the 
current  value  of  x,  producing  a  new  current  value.  Thus,  the  current  value  of  x  reflects  all 
changes  made  by  committed  activities. 

Each  activity  has  its  own  "view"  of  the  current  value  of  x,  defined  by  applying  the  operations 
in  the  activity's  intentions  list  to  x's  current  value.  An  activity's  view  reflects  all  changes  made 
by  committed  activities,  plus  changes  made  by  the  activity  itself.  A  termination  event  is 
allowed  to  occur  for  an  activity  only  if  the  operation  (again  consisting  of  the  termination  event 
and  its  corresponding  invocation  event)  is  defined  in  the  activity's  view.  This  is  clearly 
necessary:  If  the  activity  then  commits,  and  all  other  activities  abort,  the  activity  must  be 
serializable  after  the  other  committed  activities. 
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State  Components 

current  C  initially 

pending:  ACT  — INV  initially  ± 

intentions:  ACT  — •  sequence(Tg^j^i^j^)  initially  A 

committed  C  ACT  initially  0 

aborted  C  ACT  initially  0 

T ransitions:  events  involving  x 
^LCXK^®'  <commit,x,a>): 

if  aCs  committed  then  no  change  else  changes 
s.current  to  Ng^p|^i^(s. current,  s.intentions(a)) 
s. committed  to  s. committed  U  (a) 

Nj^Ock^®'  <abort,x,a>): 

changes 

s. pending  to  s  pendingfa— *±] 
s.aborted  to  s  aborted  U  {a) 

^LOCK^®’ 

when  i  is  an  invocation  event 
changes  s  pending  to  s  pending[a-*i) 

Nlock(s.  <r.x.a»: 

when 

r  is  a  termination  event 
and  s.pending(a)  *  ± 

and  Nggp|^^(s  current,  s.intentions(a)*x:<s  pending(a),r>)  *  ± 
and  x:<s.pending(a),r>  commutes  with  every  operation  in 
s  intentions(b),  for  every  b  in 
ACT -s.committed  s.aborted-{a) 

changes 

s  pending  to  s  pending[a-*  X] 

s. intentions  to  s  intentions(a— *s.intentions(a)*x:<s.pending(a),r>] 


Figure  5-1;The  machine  LOCK. 
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In  aciiiition,  a  termination  event  is  allowed  to  occur  for  an  activity  only  if  the  operation 
commutes  with  all  operations  executed  by  concurrent  activities  This  is  sufficient  to  ensure 
serializability  in  all  orders  consistent  with  the  precedes  order 

A  more  precise  explanation  of  LOCK  follows  The  strtes  of  LOCK  have  five  components 
Current  £  is  the  current  serial  state,  derived  from  the  initial  serial  state  by  performing 

the  operations  executed  by  committed  activities  Pending  ACT  — ^  INV  maps  each  activity  to 
Its  current  pending  invocation,  if  any  Intentions.  ACT  sequencefTg^i^i^^^)  maps  each 
activity  to  the  sequence  of  operations  if  has  executed  Committed  C  ACT  is  the  set  of 
committed  activities,  and  aborted  C  ACT  is  the  set  of  aborted  activities  We  denote  the 
components  of  a  state  s  £  S,  by  s  current,  s  pending,  s  intentions,  s  committed,  and 
s  aborted. 

When  an  activity  commits  for  the  first  time.  LOCK  updates  the  current  serial  state  by  applying 
the  activity's  intentions  list  to  the  state.  (Multiple  commit  events  may  occur  for  an  activity  at 
an  obiect:  we  only  want  to  apply  the  activity's  changes  to  x's  current  value  once.)  When  an 
activity  aborts,  the  current  serial  state  is  not  changed. 

Each  active  activity  has  its  own  "current  view"  of  the  current  serial  state,  defined  by  applying 
the  activity's  intentions  list  to  the  current  serial  state.  Invocation  events  are  recorded  in 
pending.  Termination  events  can  occur  for  an  activity  whenever  three  conditions  are 
satisfied: 

1  The  activity  has  a  pending  invocation. 

2.  The  resulting  operation  (obtained  by  pairing  the  pending  invocation  with  the 
termination  event)  is  defined  in  the  activity's  current  view. 

3.  The  operation  commutes  v;ith  all  operations  executed  by  concurrent  activities 
(those  that  have  not  yet  committed  or  aborted). 

When  a  termination  event  occurs,  the  corresponding  operation  is  appended  to  the  intentions 
list  for  the  activity,  and  the  record  of  the  pending  invocation  is  discarded. 

Note  that  the  "intentions  list"  for  an  activity  is  never  discarded  A  real  implementation  of  this 
protocol  would  not  keep  intentions  lists  for  aborted  activities,  or  for  committed  activities  once 
the  intentions  list  had  been  applied  to  the  current  value  of  the  object.  The  intentions  lists  for 
completed  activities  have  no  effect  on  the  behavior  of  the  nxachine:  we  keep  them  around 
solely  for  convenience  in  the  proof  of  correctness  in  the  next  section.  Similarly,  if  intentions 
lists  for  completed  activities  are  discarded,  there  is  no  need  in  a  real  implementation  to 
remember  the  sets  of  committed  and  aborted  activities.  Again,  we  keep  them  for 
convenience.  These  parts  of  the  state  of  LOCK  are  not  unlike  the  "ghost  variables"  of  [Owicki 
&  Cries  76], 


5.3  Correctness  Proof 


We  Wish  to  prove  the  following  theorem: 

Theorem  5-1:  Let  SERIAL  be  a  machine  and  let  x  be  an  obiect  with  x. serial  = 
L(SERIAL),  and  with  x  behavior  defined  to  be  the  set  of  all  dynamic  atomic 
complete  histones  involving  »  Let  LOCK  be  a  machine  as  defined  in  the  previous 
section  Then  every  complete  history  m  L(LOCK)  is  in  x  behavior. 

We  note  that  there  may  be  histories  in  x  behavior  that  are  not  in  L{LOCK):  i.e  .  dynamic 
atomicity  permits  more  histories  than  can  be  achieved  by  this  locking  protocol.  We  will 
discuss  the  differences  between  dynamic  atomicity  and  locking  based  implementations  of  it  in 
Section  5.4.2. 

Our  proof  of  the  theorem  consists  of  the  verification  of  a  collection  of  invariants  relating  the 
state  of  LOCK  with  the  histories  it  accepts  We  present  our  proof  in  three  parts.  First,  in 
Section  5.3  1.  we  present  some  technical  lemmas  about  commutativity.  Then,  in  Section 
5.3,2.  we  describe  our  main  invariant.  Finally,  in  Section  5. 3. 3,  we  present  a  series  of  lemmas 
that  complete  the  proof. 


5.3.1  Commutativity 

We  begin  with  some  notation.  In  a  diagram  such  as: 


an  arc  leading  downward  indicates  that  T(s,)  =  Sj,  and  hence  that  T  is  defined  in  s^.  If  T  and 
U  commute,  and  we  have  the  diagram; 


then  by  the  definition  of  commutativity  we  can  complete  the  diagram  to: 


The  first  lemma  provides  an  inductive  technique  for  proving  that  two  sequences  commute. 
Lemma  5-2:  Let  A^  and  B^,  for  i,j  €  {0,1),  be  sequences  of  transitions.  If 
commutes  with  for  alt  i  and  j,  then  A^’A^  commutes  with  Bjj*B^. 

Proof;  Let  s  be  such  that  A^'A^fs)  *  -L  and  Bq»B,(s)  *  ±.  We  need  to  show  that 
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A^*A^(Bjj*B^(s))  =  Bjj*B,(Ay*A^(s))  and  that  Ajj*Aj(B^*B,(s))  ±  We  have  the 
following  diagram 


which  by  the  hypotheses  ol  the  lemma  can  be  completed  to 


The  followin"  c.  rollary  extends  the  lemma  to  sequences  composed  of  more  than  two  parts 
Corollary  5-3:  Let  A  ,  1  <i<m,  and  B^,  1  <j<n.  be  sequences  of  transitions,  and 
let  A  =  A  ‘...‘A  and  B  =  B  ♦...♦B  .  If  A  commutes  with  B  for  all  i  and  j,  then  A 

1  m  1  n  I  j 

commutes  with  8. 

The  following  lemma  addresses  the  situation  when  we  have  a  collection  of  more  than  two 
sequences  that  commute  pairwise. 

Lemma  5-4:  Let  S  be  a  state,  and  let  T.  l  <i<n,  be  sequences  of  transitions  such 
that: 

1 .  T  is  defined  in  S  for  afl  i. 

I 

2  T.  commutes  with  T  for  all  t  and  j,  1  <i<j<n. 

Let  i1  .i2....,in  be  a  permutation  of  1,2 . n.  Then: 

1.T,.T,.....T„(S)^± 

2  T,-V...-TJS)  =  T,.T,.....T„(S) 

Proof:  The  proof  proceeds  by  induction  on  n  The  case  when  n  =  1  is  trivial  The 
case  when  n  =  2  follows  directly  from  the  definition  of  commutativity. 

For  the  induction  step,  assume  that  the  lemma  holds  for  fewer  than  n  sequences 
Let  I  be  such  that  ij  =  l  (so  T  =  T^)  By  the  induction  hypothesis, 
and  T  ,-  .-T^  n*  •  •T,n(S)  =  V  .-T^fS). 

Now  let  SI  =  T  ,v.,.T^^  „(S)  Since  T  ,*  ..-T^^  „*  ’TJS)  *  1,  it  follows 
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that  Si  ^  _L  and  T ,  ‘T  is  defined  tn  Si 

By  Corollary  5  3  commutes  with  T^v.  'T^.  ,,  ^lOti)*  *^in 

Since  Tj  is  defined  m  S.  and  so  is  ^2*  *^0'  ^2’  proves  the 

first  half  of  the  lemma. 


Now,  since  is  defined  in  S.  and  so  is  it  follows  from  the  definition  of 

commutativity  that  is  defined  in  Si.  Therefore  ^j*..,*T^^(Sl))  = 

T,  (T,(S1)). 

1(1  ♦  1)  in'  1' 

The  following  equalities  show  the  second  half  of  the  lemma: 

T,.T,.,...T„(S)  =  T^.....T„(T,(S)) 

=  T,(T,-,..-T^{S)) 

=  T,(T,-..-T„.,)-T^,^„...,.T.^(S)) 


1(1- 

1,-  -TJSI)) 

1(1 -► 

• 

') 

..•TJT,(S1)) 

1(1  + 

• 

n  ' 

*Vn(S)) 

i(/  + 

• 

1) 

•T.W,- 

•  * 

i1 

^,2* 

The  second  line  follows  since  T,  commutes  with  Tj*...*!^.  The  remaining  lines 
follow  from  equalities  argued  above. 


5.3.2  On-line  Dynamic  Atomicity 

In  this  section  we  define  the  main  invariant  to  be  proved  about  the  histories  in  L(LOCK).  We 
actually  define  two  properties:  strong  dynamic  atomicity,  and  on-line  dynamic  atomicity. 

Let  X  be  an  object  and  M  a  machine,  with  x. serial  =  L(M).  We  say  that  a  history  h  is  strong 
dynamic  atomic  at  x  if  the  following  conditions  are  satisfied; 

•  h|x  is  dynamic  atomic. 

•  if  77  and  T2  are  total  orders  on  activities  consistent  with  precedes{h\x),  then 

opseg{serial(permanent{h]x',.  77)))  = 

N..(l.,.  opseq{serial{permanent{h\x),  T2))). 

M  M 

In  other  words,  the  final  state  of  M  resulting  from  executing  the  operations  in 
senal{permanent{h\x}.  7)  does  not  depend  on  T. 

We  say  that  a  history  h  is  strong  dynamic  atomic  if  it  is  strong  dynamic  atomic  at  all  objects  x. 
The  following  lemma  follows  easily  from  the  definitions: 

Lemma  5-5:  If  h  is  strong  dynamic  atomic,  h  is  also  dynamic  atomic. 


t 


/I 


Till-  following  e>  jnipic’  illustrates  flow  strong  ())naritit  atomic  it>  and  d',  namic  atomu  ity  differ 
In  Section  4  3  3  we  illustrated  a  problem  with  dynamic  atomicity  namely  ttial  concurrent 
activities  can  enqueue  items  on  a  FIFO  queue,  but  that  the  items  cannot  be  dequeued  later 
We  repeat  the  example  history  here 

<enqueue(l).z.a> 

<enqueue(2).z.b> 

<ok  z.a> 

<ok,z,b> 

<comfhjt,z,b> 

<cotnmit,z,a> 

<dequeue,z,c> 

<?,z,c> 

<commit,z,c> 

The  problem  is  that  the  result  returned  by  the  dequeue  operation  depends  on  the  order  In 
which  a  and  b  are  serialized  Consider  the  following  prefix  h  of  this  history: 

<enqueue(1).z,a> 

<enqueue(2),z,b> 

<ok,z,a> 

<ok,z,b> 

<commif,z,b> 

<commif,z,a> 

This  prefix  is  not  strong  dynamic  atomic:  The  state  of  the  machine  M  resulting  from  serializing 
a  before  b  is  the  sequence  1*2,  while  the  state  resulting  from  serializing  b  before  a  is  the 
sequence  2*1. 

This  example  is  an  instance  of  a  general  problem  with  dynamic  atomicity  If  an 
implementation  allows  a  history  that  is  not  strong  dynamic  atomic,  it  may  have  difficulty 
responding  to  later  invocations.  There  are  two  solutions  to  this  problem.  One  is  to  use  hybrid 
atomicity,  as  discussed  in  Section  4.3.3;  Once  activities  commit,  they  can  be  totally  ordered 
by  their  timestamps.  The  other  is  to  strengthen  dynamic  atomicity,  requiring  strong  dynamic 
atomicity  instead  This  latter  solution  results  in  a  loss  of  concurrency:  however,  the  lost 
concurrency  does  not  seem  useful,  since  it  leads  to  situations  where  an  activity  invokes  an 
operation  and  never  gets  a  response.  All  implementations  of  dynamic  atomicity  that  we  have 
studied  produce  histories  satisfying  strong  dynamic  atomicity 

Our  second  property,  on-line  dynamic  atomicity,  seems  fundamental  to  all  pessimistic 
implementations  of  dynamic  atomicity  We  say  that  a  history  h  is  on  line  dynamic  atomic  at  x 
if.  for  every  set  C  of  activities  such  that  committed{n\K)  C  C  C  ACT  ■  aboried(h\x),  the 
following  conditions  are  satisfied. 

hl»  |C  IS  serializable  in  every  total  order  consistent  with  precedes(h|x). 

-if  Ft  and  T2  are  total  orders  consistent  with  precedes{h\x).  then  N^(l^. 
opseq(senat{h\K\C.  J 1)))  =  N|^(l|^.  opseq(ser;a/(n|x|C.  T2))) 


* 


•i - 
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Pessimistic  implementations  liave  the  property  that  once  an  activity  executes  an  operation,  it 
can  commit  at  any  time  without  violating  dynamic  atomicity  Consider  a  history  h  and  all 
extensions  of  h  obtained  by  appending  commit  events  for  some  of  the  active  activities  in  h\ 
on  line  dynamic  atomicity  simply  requires  that  all  these  histories  be  strong  dynamic  atomic 

We  say  that  a  history  h  is  on  line  dynamic  atomic  if  it  is  on  line  dynamic  atomic  at  all  objects  x. 

The  following  lemma  is  immediate; 

Lemma  5-6:  If  h  is  on  line  dynamic  atomic,  h  is  also  strong  dynamic  atomic. 


5.3.3  Verification  of  LOCK 

We  will  now  present  a  series  of  lemmas  describing  properties  of  the  machine  LOCK  and  the 
histones  accepted  by  it.  The  final  lemma  completes  the  proof  of  Theorem  5- 1 . 

Recall  that  commit-order(h)  is  the  partial  order  on  activities  containing  all  pairs  <a.b'>  such 
that  the  first  commit  event  for  a  in  h  occurs  before  the  first  commit  event  for  b. 

The  first  lemma  describes  a  number  of  simple  relationships  between  a  history  accepted  by 
LOCK  and  the  final  state  of  LOCK  after  accepting  the  sequence. 

Lemma  5-7:  Suppose  h  is  a  history  in  the  language  of  the  machine  LOCK.  Lets 
=  Then: 

1.opseq(h|a)  =  s.intentions{a) 

2.  h|a  ends  in  the  invocation  event  <;,x,a>  *=>  s.pending(a)  =  / 

3.  a  C  committed(h)  =»  a  C  s.commitled 
4  a  €  aboned(h)  <=>  a  C  s.aborted 

5.  a  *  b  A  a.b  i  committed{h)  U  aborted{h)  =»  s.intentions(a)  commutes 
with  s  intentions{b) 

6.  Let  T  be  a  total  order  consistent  with  commit -orderih).  and  let  permanent 
=  opseq{i,enal{h\committed{h),  T)).  Then  s. current  =  ^'Iserial^^SERIAL’ 
permanent). 

Proof:  The  proof  is  by  induction  on  the  length  of  h.  For  illustration  we  will  prove 
the  fifth  property,  showing  that  the  sequences  of  operations  executed  by  two 
active  activities  commute. 

The  basts  case,  when  h  =  A,  is  trivial. 


For  the  induction  step,  suppose  b*  A,  and  assume  that  the  fifth  property  holds  for 
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all  histones  in  L(LOCK)  tliat  are  shoiter  thaiWi  Then  h  -  Av  foi  some  liislory  A  in 
L(LOCK)  and  some  event  e  Since  A  is  slioMer  tlian  h.  the  fifth  property  liolds  for  A, 
Note  that  if  a  <I  conin>itted(h)  U  abortecUh).  then  a  d  comn)itled{k)  U  aboncd(h). 
and  similarly  for  b.  There  are  two  cases,  depending  on  the  type  of  e. 

If  e  IS  a  commit,  abort,  or  invocation  event,  then  s  intentions  =  A(l,  intentions. 
and  tlie  result  follows  from  the  induction  hypothesis. 

If  e  is  a  termination  event  <r.»  c>.  s  intentions  differs  from  A(l,  intentions  only 
at  c.  If  and  S^c.  then  the  result  again  follows  from  the  inciuction  hypothesis 
Suppose  without  loss  of  generality  that  a=c  From  the  definition  of  LOCK  it 
follov^s  that  s  intentions(a)  =  intentions{a)‘<k(\^^^).pending{a).r>.  and 

by  the  induction  hypothesis  k{\^^^).inteniions(a)  commutes  with  s  intentions{b). 
By  Corollary  5  3  and  the  precondition  on  e,  <k(\^^^).pending(a).r>  commutes  with 
s  intentionsio).  The  result  then  follows  from  Lemma  5-2. 


The  next  lemma  shows  that  the  sequence  of  operations  executed  by  an  active  activity  is 
always  defin  ed  m  the  current  serial  state. 

Lemma  5-8:  Suppose  h  is  a  history  in  the  language  of  the  machine  LOCK.  Let  s 

a  ^  committed(h}  U  aborted(h)  =>  s.mteniions(a)  is  defined  in 
s. current 

Proof:  The  proof  proceeds  by  induction  on  the  length  of  h.  The  basis  case,  when 
n  =  A,  is  trivial. 


For  the  induction  step  suppose  h^A,  and  assume  that  the  lemma  holds  for  all 
histories  in  L(LOCK)  that  are  shorter  than  h.  Then  h  =  k’e  for  some  history  k  in 
L(LOCK)  and  some  event  e  Since  k  is  shorter  than  h.  the  lemma  holds  for  k.  Note 
that  if  a  committed(b)  U  aborted{h),  then  a  €  commitiedfk)  U  aborted(k).  There 
are  three  cases,  depending  on  the  type  of  e. 

If  e  IS  an  abort  event  or  an  invocation  event,  then  s  intentions  -  intentions 

and  s  current  =  A(I^q^^). current.  The  result  follows  from  the  induction 
hypothesis. 

If  e  is  a  termination  event,  the  precondition  for  e  ensures  that  the  lemma  holds  for  h 
if  It  holds  for  k. 


If  e  IS  a  commit  event  <comm/t.x.ti>.  then  s  infenticns  =  tr(I^Q^^)./nfent/ons.  (Note 
that  since  a<Jcpnjni//fcd(n) )  If  bCcomrn;ffed(A)  then  A(I|^q^  )  =  and 

the  result  follows  from  the  induction  hypothesis.  Suppose  bicommitted{k). 


74 


By  the  induction  hypothesis.  ti(lj^^^).//in  ;i/«’n‘.(,i)  is  defined  in  ''(Ilqck^ 

Since  b^commiiiedW  and  h  is  well  formed  k(\  )  iDteniion^ib)  is  defined  in 

a(Ilock^'^‘^'’'^^^-  Lemma  5  7  A(l^^i^).(nrenf/ons(b)  commutes  with 

k(\^Q^^).lntentions{a).  By  the  definition  of  commutativity.  A(l|^^^)./nrenr/ons(a)  is 
defined  in  ^serial  mieniiunslb))  which  is 

An  obvious  corollary  of  the  above  two  lemmas  is  that  h(l,  current  is  never  ±,  implying 

LtXyfN 

that  hlcommiiiedih)  is  serializable  m  any  order  consistent  with  commii-order{h). 

The  penultimate  lemma  shows  that  the  active  activities  can  be  serialized  m  any  order  starting 
in  the  current  serial  stale,  and  the  resulting  final  serial  stale  does  not  depend  on  the  order 
Lemma  5-9:  Let  h  be  a  history  in  the  language  of  the  machine  LOCK,  and  let  s  = 
n(l|^OCK^  Suppose  A  C  ACl-aborled{b)-comnvited(h).  and  let  T  be  any  total  order 
of  activities  Then  Ng^p|^i_{s.curren/,  opseq(ser.a;(n|A,T)))  is  defined  and  does  not 
depend  on  T. 

Proof;  Let  at . an  be  the  elements  of  A.  By  Lemmas  5-7  and  5  8.  opseQ(h\ai)  is 

defined  in  s. current  lor  all  i.  By  Lemma  5-7,  opseq(h|a/)  commutes  with  opseq(hfaj) 
for  all  i  and  j,  1  <i<j<n.  The  result  follows  from  Lemma  5-4. 

The  final  lemma  proves  that  every  history  in  L(LOCK)  is  on-line  dynamic  atomic.  This 
completes  our  proof  of  Theorem  5-1,  since  by  Lemma  5-6.  every  history  (and  hence  every 
complete  history)  in  L(LOCK)  is  therefore  dynamic  atomic. 

Lemma  5-10:  Suppose  n  is  a  history  in  L(LOCK),  Then  n  is  on  line  dynamic 
atomic. 

Proof:  Since  h  =  h|)r,  it  suffices  to  show  that  h  is  on  line  dynamic  atomic  at  x.  We 
repeat  the  conditions  lor  on-line  dynamic  atomicity  here:  h  is  on  line  dynamic 
atomic  at  x  if,  for  every  set  C  of  activities  such  lhai  immittedfhlx)  C  C  C  ACT 
■  aborted(/)lx).  the  following  conditions  are  satisfied: 

•  h|x|C  is  serializable  in  every  total  order  consistent  with  precedes(blx). 

-if  Tt  and  T2  are  total  orders  consistent  with  precedes(n|x).  then 
opseci{serial{h\x\C,T1)))  =  opseQ(seria/(h|x|C,  72))). 

The  proof  proceeds  by  induction  on  the  length  of  h.  The  basis  case,  when  h  =  A, 
is  trivial. 

For  the  induction  step,  suppose  h*\.  and  assume  that  the  lemma  holds  for  all 
histones  in  L(LOCK)  that  are  shorter  than  h.  Then  h  =  H‘e  for  some  history  *  in 
L(LOCK)  and  some  event  e.  Since  k  is  shorter  than  h,  the  lemma  holds  for  A. 


Let  C  be  such  that  con)n)iiieci{li)  C  C  C  ACT  jborted{h).  and  let  J )  and  1?  be 
total  orders  consistent  with  precedes(h). 


7 


First,  note  that  precedes{k)Cprecedes{h).  committed{>- ,Ccommilled{h).  and 
aboried{k)Caborted(h).  Thus,  C,  T1  and  T2  satisfy  the  conditions  of  the  definition 
of  on-line  dynamic  atomicity  for  A.  There  are  now  two  cases,  depending  on  the 
type  of  e. 

If  e  is  a  commit,  abort,  or  invocation  event,  note  that  opseq  throws  away  pending 
invocation  events  (those  without  corresponding  termination  events)  and 
completion  events  Thus,  opseq(senal{h\CJi))  =  opseq{senal(k\CJi))  Since  the 
lemma  holds  for  A ,  it  also  holds  for  h. 

Now  suppose  that  e  is  a  termination  event  O.t.a'y  This  is  the  difficult  case.  Note 
that  if  aiC  then  n|C  =  A|C,  and  the  result  follows  from  the  induction  hypothesis 
Assume  that  a€C. 

Let  T  be  a  total  order  of  the  activities  in  C  such  that  the  committed  activities  in  h 
appear  in  commit  order(h).  a  appears  next,  and  the  remaining  activities  appear  in 
arbitrary  order,  Note  that  t  is  consistent  with  precedes{h).  We  will  first  show  that 
hlC  is  serializable  in  the  order  T,  and  then  show  that  for  any  order  U  consistent  with 
precedes(h).  opseq(senal(h\C.  T)))  =  Nggp|^L('sERiAL' 

opseq{seriaHh\C.  U))).  This  suffices  to  prove  the  lemma. 

Let  A  =  C-committed(h).  The  sequence  opseq(senal(h\CJ))  can  be  written  as 
opseq{serial(h\commilted{h).commit  order{h)))  •  opseq{seriat{h\A,T)).  By  Lemma 

5-7,  h(\^^^^).current  =  ’^SERial^’serial' 

opseq(senal(h\committed{h),commii  order(h)))).  By  Lemma  5-9, 

Ncco,*,  (^(1,  rv-i^)-ct>rrenf,  opseq{senal{h\A.T))  is  defined.  Thus,  h|C  is  serializable 

ScHIAL 

in  the  order  T. 

Now  suppose  U  is  consistent  with  precedes(b).  The  sequence  opseq(senal(h\C.U)) 
can  be  written  as  Si  •opseq(ti(a)*S2,  where  SI  =  opseq{senal{h\Cl ,U)].  S2  = 
opseq{serial(h\C2,U))^  and  committed(h)CCl .  Note  that  Si 
opseq(ser(a/(A|C/,L/)),  since  aid. 

Let  V  be  a  total  order  on  Cf  in  which  the  elements  of  commiited{h)  occur  first  in 
commit  order{h).  following  by  the  remaining  elements  of  Cl  in  arbitrary  order.  Let 

NSI  =  opseq{senal{k\C1  .V)).  By  the  inductive  hypothesis,  = 

*^SERIAL^'sERIAL'^^^^ 
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Now  let  NS2  =  opsi^qi^riuiU^C  1  CLii)imitie(i{h).V)).  The  sequence  NSl  can  be 
written  as  opseq(^t‘rial{h\commiited{/i),commii  order{h)))  •  NS2.  The  following 
equalities  show  the  desired  result: 


^SERIAL  f*Sf  rial 


opseq{senal{h\C,U))) 
SERIAL'’SERIAL' 


N..,  (Uto,*,  Si  •opseq(n|a)*S2) 


N 


NSt  'opseq{h\a)‘S2) 


serial'  serial 
■  *^SERIAL^’sERIAL' 

opseq[senal(h\conimitied(h),commit  order [h)))‘NS2‘opseq(h\a)‘S2) 

^  Ng^P^i^i^(n(I^Q^^).curren/,NS2*opseq(n|a)*S2) 

The  last  ime  follows  from  Lemma  5-9:  the  others  follow  from  equalities  argued 
above. 


5.4  Remarks 

This  section  consists  of  two  parts.  In  the  first  we  discuss  the  protocols  in  [Bernstein  ef  a/. 
81 ,  Korth  81a],  In  the  second  we  illustrate  limitations  of  locking  protocols,  showing  that  there 
IS  potentially  useful  concurrency  permitted  by  on  line  dynamic  atomicity  that  cannot  be 
achieved  by  locking. 


5.4.1  Existing  Protocois  Revisited 

In  this  section  we  discuss  the  relationship  between  our  general  protocol  and  the  locking 
protocols  in  [Bernstein  el  al  81,  Korth  81aj  We  argue  tnat  these  other  protocols  are  special 
cases  of  our  protocol. 

The  protocols  in  [Bernstein  el  al  81,  Korth  81a]  are  modeled  using  the  scheduler  model  (see 
Figure  3-1)  The  scheduler  determines  whether  an  invocation  can  be  executed:  if  so,  the 
invocation  is  passed  to  the  storage  module  The  storage  module  executes  invocations  in  the 
order  in  which  they  are  received,  changing  state  and  determining  the  results  to  be  returned, 
(We  note  that  the  presentations  m  [Bernstein  ef  a/.  81,  Korth  61a]  do  not  consider  recovery. 
The  protocols  are  presented  as  characterizing  the  behavior  of  committed  activities,  and  the 
implementation  of  recovery  is  not  discussed,) 

As  discussed  above,  the  protocols  in  [Bernstein  et  al  81 ,  Korth  81a]  require  invocations  to  be 
total  and  deterministic.  This  means  that  we  can  treat  invocations  as  functions;  If  the  serial 
specification  of  an  object  is  described  by  a  machine  M  (with  state  domain  S. .),  and  TERM  is 
the  set  of  termination  events,  we  can  define  a  function  perform :  X  TERM  for  each 

invocation  event /.  This  function  is  defined  by  pefform^(s)  =  <s  ,r>  such  that  Nj^(s,<i.r>)  =  s  ’. 


TIte  storage  moilule  fcxecutes  an  invocation  '  using  /ii-rfern/^  l(  the  iu:i  -nt  slate  of  the 
storage  module  is  s.  and  per/onn  (s)  =  <s'.f>.  then  the  new  state  ol  the  storage  module  after 
executing  r  is  s'  and  the  result  returned  is  the  event  / 

Commutativity  is  defined  for  invocation^  rather  than  opciahoni,  m  [Bernstein  et  a'  8l  Korth 
8la):  Two  invocations  i  and  j  commute  if  pi-ilomi  °  peilorrn  =  in-itonn  °  perlom'  v.heie 
denotes  contposition  of  functions  (If  invocations  are  restricted  to  tie  total  and 
deterministic  tliis  is  equivalent  to  saying  that  <i.c;>  commutes  with  <,  r>  for  all  termination 
events  q  and  r )  The  scheduler  schedules  an  invocation  lor  an  activity  if  it  commutes  with  all 
other  invocations  already  executed  by  concurrent  activities 

Recovery  is  not  covered  in  [Bernstein  et  a!  81.  Korth  8la];  rather,  they  rely  on  unstated 
assumptions  about  tfie  operation  of  the  storage  module  in  handling  abort  events  for  activities 
The  description  in  the  papers  and  our  explanation  above,  only  cover  committed  activities  It 
is  not  clear  hov;  one  would  implement  recovery  using  the  scheduler  model:  the  intent 
in  [Bernstein  et  al  81 .  Korth  81  a]  is  clearly  to  use  some  sort  of  undo  log  but  this  approach  is 
complicated  by  the  fact  that  not  all  operations  have  natural  Inverses  (consider,  for  example, 
the  insert  operation  on  a  set  object)  One  could  use  intentions  lists,  but  this  requires  a  mote 
complex  notion  of  what  it  means  for  the  storage  module  to  "execute"  an  invocation  once  it 
has  been  scheduled  (Indeed,  one  would  then  have  a  description  much  closer  to  our  machine 
LOCK,  and  much  less  like  the  scfiedufer  model.) 

From  the  above  definition  of  the  protocols  in  [Bernstein  et  ai  81 ,  Korth  81a].  it  is  easy  to  show 
that  every  history  involving  committed  activities  that  is  permitted  by  these  protocols  is  also 
permitted  by  our  protocol  The  converse,  however,  is  not  true  One  reason  is  that  we  permit 
objects,  such  as  semiqueues,  with  partial  non  deterministic  invocations  The  protocols 
in  [Bernstein  et  al  81 ,  Korth  81a]  do  not. 

The  other  reason  is  that  our  locking  protocol,  unlike  the  protocols  in  [Bernstein  et  al 
81.  Korth  81a].  permits  information  about  the  results  of  executing  an  invocation  (i.e..  the 
termination  event)  to  be  used  m  scheduling  invocations.  For  example,  consider  a  bank 
account  object  y.  with  a  serial  specification  described  by  the  machine  in  Figure  5-2.  A  bank 
account  provides  three  operations:  deposit,  withdraw,  and  balance.  Deposit  adds  a  specified 
amount  to  the  bank  account  Withdraw  withdraws  a  specified  amount  from  the  bank  account 
if  the  current  balance  is  adequate  (in  which  case  its  result  is  "ok”):  otherwise  it  leaves  the 
account  unchanged  (with  a  result  of  "no").  Balance  determines  the  current  balance  of  the 
bank  account.  Note  that  the  invocations  on  y  are  total  and  deterministic:  For  each  invocation 
/  and  every  state  s  of  the  machine  M  in  Figure  5  2,  there  exists  etiactly  one  termination  event  r 
such  that  N|^(s,<r,r>)  *  ±.  Further  note  that  the  invocation  withdraw{3)  does  not  commute 
with  the  invocation  balance  (by  the  definition  of  "commutativity"  for  invocations  given  above) 


I 


Stales  inteyets  inilially  0 


T ransitions:  {y  <deposit(i).ok>,  y:<withdraw(i),ok>, 

y  <withdraw(i),no>.  y:<balance.i>:  i  is  an  integer) 

N(s,y  <deposit(i).ok>): 
changes  s  to  s^  i 

N(s.y;<wilhdraw(i),ok>): 
when  s>i 
changes  s  to  s  i 

N(s,y;<withdraw(i),no>): 
when  s<i 

N(s.y:<balance,i>): 
when  s= i 

Figure  5-2;Senal  specification  of  a  bank  account  object  y. 


Now  consider  the  following  history: 

<withdraw(3),y,a> 

<balance,y,b> 

<no,y,a> 

<0.y,b> 

<commit,y,b> 

<commit,y,a> 

Since  the  invocation  w//hc/raw(3)  does  not  commute  with  balance,  the  protocols  in  [Bernstein 
ef  al.  81.  Korth  81a]  cannot  produce  this  history.  However,  this  history  can  be  produced  by 
our  locking  protocol,  since  the  operation  y:<withdraw[3).no>  commutes  with  the  operation 
y:<Oa/ance,0>. 


5.4.2  Limitations  of  Commutativity-based  Protocols 

All  known  two  phase  locking  protocols  are  based  on  some  notion  of  commutativity:  activities 
are  allowed  to  execute  operations  concurrently  only  if  the  operations  "commute."  As 
discussed  in  the  previous  section,  previously  existing  locking  protocols  are  special  cases  of 
our  protocol.  In  this  section  we  illustrate  how  on  line  dynamic  atomicity  permits  more 
concurrency  than  can  be  achieved  by  any  known  locking  protocol 

Consider  is  a  bank  account  objecf  y.  with  a  serial  specification  as  described  in  Figure  5  2. 
Two  operations  of  the  form  y:<deposit(i).ok>  and  y:<deposit(i),ok>  commute,  since  addition  is 
commutative  However,  two  operations  of  the  form  y:<withdraw(i),ok>  and  y:<withdraw(j),ok> 
do  not  commute:  If  the  current  balance  is  greater  than  i  and  j  but  less  than  their  sum,  then 
neither  sequence  of  both  operations  is  defined  Similarly,  y:<deposit(i),ok>  does  not  commute 
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with  y  <wiilKliaw(i).no>.  The  latter  operation  is  defined  only  m  states  s  less  than  |  if  s  i  is 
greater  than  j.  then  y:<withdraw(j),no'>  is  not  defined  m  the  stale  resulting  from  executing 
y:<deposit(i),ok>  in  state  s.  Also,  y;<deposit(i).ok>  does  not  commute  with  y  <withdraw(]).ok> 

Consider  the  following  history: 

<deposit(lO),y,a> 

<ok.y,a> 

<commit,y,a> 

<withdraw(4),y,b> 

<withdraw(3).y,c> 

<ok,y,c> 

<ok.y,b> 

<commit,y,c> 

<commit,y,b> 

This  history  is  on  line  dynamic  atomic:  It  is  serializable  in  the  orders  a  b  e  and  a  c  b.  and  the 
"final  serial  state"  does  not  depend  on  the  serialization  order.  However,  since 
y:<withdraw(4),ok>  does  not  commute  with  y:<withdraw(3).ok>,  and  b  and  c  execute  these 
operations  concurrently,  this  history  is  not  permitted  by  locking  protocols. 

Similarly,  the  following  sequence  is  on  line  dynamic  atomic  but  is  not  permitted  by  locking 
protocols: 

<deposit(1),y,a> 

<Ok,y,a> 

<cornmit,y,a> 

<deposit{l),y,b> 

<ok,y,b> 

<withdraw(1),y,c> 

<Ok,y,c> 

<commit,y,b> 

<commit.y,c> 

On  line  dynamic  atomicity  allows  withdraw  operations  to  be  executed  concurrently  with 
deposit  operations  as  long  as  the  deposits  are  not  needed  to  cover  the  withdrawals,  or  the 
withdrawals  are  too  large  to  be  affected  by  the  deposits. 

Locking  implementations  of  on  line  dynamic  atomicity  achieve  less  than  maximal 
concurrency  because  they  do  not  use  two  kinds  of  information  available  to  them.  First, 
locking  protocols  are  conflict-based:  synchronization  is  based  on  a  pair  wise  comparison  of 
operations  executed  by  concurrent  activities.  In  contrast,  on  line  dynamic  atomicity  depends 
on  the  sequences  of  operations  executed  by  activities.  Second,  locking  protocols  are  history 
independent:  synchronization  is  independent  of  past  history,  in  particular  the  operations 
executed  by  committed  activities.  In  contrast,  on  line  dynamic  atomicity  depends  on  the 
entire  history:  witness  the  concurrent  execution  of  withdraw  operations  when  enough  money 
has  been  deposited  by  committed  activities  to  cover  all  of  the  withdrawals 
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An  example  of  a  flKjht  reservation  list  for  an  airline  reservation  cfalaljase  is  presenteii 
in  (Reuter  82]  This  example  is  similar  to  our  bank  account,  and  also  illustrates  the  limitations 
of  locking. 

A  similar  situation  anses  with  semiqueue  objects  (see  the  serial  specification  in  Figure  2  3). 
Deq  operations  do  not  always  commute  with  oilier  Oeq  operations  or  with  pnq  operations,  but 
on  line  dynamic  atomicity  permits  dcq  s  to  be  executed  with  enq  s  and  other  a&q  s  as  long  as 
there  are  enough  enqueued  items  to  cover  all  the  deg's 

Locking  protocols  are  clearly  useful  for  many  applications,  and  can  be  implemented  relatively 
easily.  The  examples  above  illustrate,  however,  that  there  may  be  applications  for  which 
locking  protocols  are  inadequate  Later  m  this  dissertation  we  will  present  implementations  of 
the  semiqueue  and  tlie  bank  account  that  achieve  the  kind  of  concurrency  illustrated  above. 
It  remains  to  be  seen  whether  the  increased  concurrency  is  worth  the  added  complexity  of  the 
implementations. 
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Chapter  Six 

Linguistic  Support  in  Argus 


In  the  next  two  chapters,  and  in  the  appendix,  we  consider  how  atomic  types  can  be 
implemented  Our  purpose  is  two  fold.  First,  we  will  provide  several  detailed  examples  of 
implementations  of  highly  concurrent  atomic  types  Second,  we  will  evaluate  alternative 
programming  language  constructs  for  implementing  atomic  types. 

Our  approach  in  these  chapters  is  informal.  We  do  not  provide  formal  specifications  of  the 
types  used  in  examples,  nor  do  we  formally  verify  the  correctness  of  example 
implementations.  Taking  a  formal  approach  to  these  issues  would  require  developing  a 
formal  specification  language  and  deductive  system,  and  a  formal  semantics  for  the  language 
in  which  implementations  are  expressed.  Such  work  is  well  beyond  the  scope  of  this 
dissertation. 

We  limit  our  scope  in  these  chapters  in  two  ways.  First,  we  focus  on  implementing  dynamic 
atomic  types.  Second,  we  restrict  our  attention  to  pessimistic  (as  opposed  to  optimistic  [Kung 
&  Robinson  81  ])  implementations.  In  our  remarks  at  the  end  of  Chapter  7  we  will  discuss  what 
can  be  concluded  about  other  kinds  of  atomic  types,  and  about  optimistic  implementations. 

We  use  Argus  [Liskov  &  Scheifler  82,  Liskov  et  at.  83]  as  a  vehicle  for  describing 
implementations.  The  mechanisms  in  Argus  support  a  program  structure  in  which  no  user 
code  is  executed  when  activities  commit  or  abort.  In  this  chapter  we  present  the  Argus 
approach.  In  Chapter  7  we  will  introduce  extensions  to  Argus  to  support  an  alternative 
program  structure,  and  discuss  the  relative  merits  of  the  two  approaches. 

In  our  formal  analysis  of  atomicity  we  restricted  our  attention  to  single  level  activities  In  our 
study  of  implementations,  we  will  permit  activities  to  be  nested,  and  will  explore  how 
implementations  can  support  atomicity  for  nested  activities  We  will  discuss  the  extensions 
needed  to  cope  with  nesting  in  Section  6,2. 

Each  of  our  example  implementations  ensures  on  line  dynamic  atomicity  (see  Section  5  3  2). 
In  addition,  all  of  our  examples  are  implemented  using  c/usfers  [Liskov  ef  a/  83],  a  data 
abstraction  mechanism  originally  developed  for  CLU  [Liskov  ef  at  81]  The  view  of  types 
supported  by  clusters  is  slightly  different  from  the  dassTike  view  (as  in  Simula  [Dahl  ef  a/  70] 
and  Smalltalk  [Robson  81])  taken  in  our  formal  model.  These  differences,  however,  are 
unimportant  for  our  purposes,  we  will  discuss  them  briefly  later  in  this  chapter. 

The  rom.'iindc-r  of  this  chapter  is  organized  as  follows:  In  Section  6.1,  we  discuss  the  issues 
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involved  in  implfinenting  an  atomic  type  Tlien.  in  Section  6.2  we  discuss  atomicity  of  nested 
activities,  and  illustrate  how  the  definition  of  dynamic  atomicity  applies  to  nested  activities 
Next,  in  Section  6  3  we  discuss  the  differences  between  the  Argus  view  of  types  and  the  view 
taken  in  our  formal  model  Finally,  in  Section  6  4.  we  discuss  the  linguistic  support  provided 
by  Argus,  illustrating  its  use  with  a  detailed  example. 


6.1  Issues 

Like  an  implementation  of  a  data  type  in  a  sequential  language,  an  implementation  of  an 
atomic  type  must  define  a  representation  lor  objects  of  the  type  and  must  provide 
implementations  for  each  operation  of  the  type  m  terms  of  that  representation  However,  the 
implementation  of  an  atomic  type  must  also  ensure  appropriate  synchronization  and  recovery 
for  activities  using  objects  of  the  type.  The  necessary  synchronization  and  recovery  are 
defined  by  the  type  s  specification,  and  depend  on  the  local  atomicity  property  satisfied  by  the 
type. 

To  provide  synchronization  and  recovery  for  activities  using  objects  of  an  atomic  type,  it  is 
necessary  to  update  the  representation  of  objects  as  activities  commit  and  abort.  In  Argus, 
the  programmer  relies  on  the  system  to  update  the  representation  We  call  this  an  implicit 
approach.  An  alternative  is  for  the  programmer  to  supply  code  that  is  run  when  activities 
complete  to  update  the  representations  of  objects  We  call  this  an  explicit  approach.  In  this 
chapter  we  focus  on  the  implicit  approach  as  supported  by  Argus  We  will  discuss  the  explicit 
approach  and  compare  the  two  alternatives  in  Chapter  7. 

In  addition  to  providing  appropriate  synchronization  and  recovery  tor  activities  using  objects 
of  the  type,  an  implementation  of  an  atomic  type  must  cope  with  internal  concurrency  and 
failures  An  operation  invoked  by  an  activity  is  not  executed  instantaneously:  It  may  fail  after 
completing  only  some  of  the  steps  described  by  its  implementation.  Operations  invoked  by 
concurrent  activities  may  also  run  concurrently.  Steps  must  be  taken  by  the  implementation 
of  the  type  to  manage  concurrency  and  failures  of  operations.  (We  avoided  this  issue  in  our 
analysis  of  LOCK  in  Chapter  5  by  assuming  that  the  transitions  of  LOCK  were  instantaneous.) 


6.2  Nested  Activities 

Nested  activities,  or  subactivitics.  are  used  for  composing  activities  into  larger  activities.  They 
are  also  a  mechanism  for  limiting  the  scope  of  failures,  and  for  introducing  concurrency 
within  an  activity. 

An  activity  may  contain  any  number  of  subactivilies,  some  of  which  may  be  performed 
sequentially,  some  concurrently  Atomicity  for  nested  activities  means  that  the  internal 


structure  of  an  activity  cannot  be  observeii  outside  the  activity,  m  other  words  ttie  activit)  as 
a  whole,  including  all  its  nested  activities,  is  serializable  with  respect  to  other  activities  at  the 
same  level  If  the  order  in  which  nested  activities  appear  to  be  executed  does  not  matter 
nested  activities  can  be  executed  concurrently  without  any  additional  synchronization 

Nested  activities  can  commit  or  abort  independently,  and  a  nested  activity  can  abort  without 
forcing  its  parent  activity  to  abort  However,  the  commit  of  a  nested  activity  is  relative  to  its 
parent  Even  if  a  nested  activity  commits,  it  will  have  no  effect  if  its  parent  later  aborts  A 
top  level  activity  has  no  parent:  its  effects  cannot  be  undone  once  it  has  committed  (See 
(Reed  78  Moss  81 ,  Liskov  u  Scheifler  82]  for  more  detailed  discussions  of  nested  activities  ) 

As  discussed  in  Chapter  1,  nested  activities  form  a  natural  tree  structure  with  eacn  activity 
appearing  as  the  parent  of  its  subactivities  We  can  define  the  notions  of  child  sibimg 
ancestor,  proper  ancestor,  descendant,  and  proper  descendant  in  the  usual  way  As  a 
technical  device,  we  assume  the  existence  of  a  single  ''roof  activity  which  is  the  parent  of  an 
top  level  activities. 

The  notion  of  the  least  common  ancestor  of  two  activities  and  the  related  notion  of  »  ;•  h 
are  keys  in  extending  dynamic  atomicity  to  cover  nested  activities  K  a  and  t-  are  activities 
then  the  least  common  ancestor  of  a  and  b  is  the  ancestor  of  both  a  and  b  which  is  a 
descendant  of  alt  other  ancestors  common  to  a  and  £>  For  example  consider  the  following 
tree  of  activities: 


d 


b 


The  ancestors  common  to  a  and  b  are  c  and  d.  c  is  the  least  common  ancestor  of  a  and  b 

Informally,  we  say  that  an  activity  b  is  visible  to  an  activity  a  il  b  has  committed  up  to  the  level 
of  the  least  common  ancestor  of  a  and  b.  For  example  suppose  that  a  and  b  are  subactivities 
of  the  same  activity.  Then  b  is  visible  to  a  if  and  only  if  b  has  committed  As  another  example 
consider  the  following  tree  of  activities: 

ten 

•  bp 

I 

b 

b  is  visible  to  a  if  and  only  if  b  and  its  parent,  bp.  have  com-  ‘d  II  b  is  not  visible  to  a  then 
either  b  (or  one  of  its  ancestors)  has  aborted,  or  b  (or  one  ot  its  ancestors)  is  still  active  in 
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either  case,  a  should  not  be  permitted  to  "depend  on"  b's  effects,  since  if  b  aborts  a  must 
then  be  aborted  as  well  (Note  that  the  least  common  ancestor  of  two  top  level  activities  is  the 
"root"  activity,  thus,  one  top  level  activity  is  visible  to  another  if  and  only  if  it  has  committed  ) 

We  extend  our  notion  of  the  precedes  order  as  follows:  ’-Ve  say  that  b  precedes  a  in  an 
execution  if  b  is  visible  to  a  when  a.  or  a  descendant  of  a,  executes  an  operation.  If  o 
precedes  a.  then  dynamic  atomicity  only  requires  that  b  be  serializable  before  a  If.  however, 
a  and  b  are  unrelated  by  the  precedes  order,  then  a  and  b  must  be  oerializable  in  either  order. 
(On  line  dynamic  atomicity  also  requires  that  the  final  "serial  state"  not  depend  on  the 
serialization  order.) 

For  example  consider  the  tree  of  activities  described  above,  and  suppose  activities  execute 
the  following  steps  on  a  semiqueue  object  y; 

<enq(1),y,b> 

<ok,y.b> 

<commit,y,b> 

<deq,y.a> 

<1.y,a> 

<commit.y,bp> 

<commit,y,a> 

<commit,y,lca> 

In  this  history  b  does  not  precede  a.  yet  a  is  serializable  only  after  b.  Thus,  this  history  is  not 
dynamic  atomic  On  the  other  hand,  the  following  history  is  dynamic  atomic: 

<enq(1),y,b> 

<ok,y,b> 

<commit,y,b> 

<deq,y,a> 

<commit,y,bp> 

<l,y,a> 

<commit,y,a> 

<commit,y,lca> 

If  an  activity  a  is  executing  an  operation  on  an  object,  then  a  s  "view"  of  the  object  includes 
the  effects  of  all  activities  that  are  visible  to  a  The  results  returned  by  the  operation  are 
allowed  to  "depend  on  "  the  activity  s  view,  but  must  be  independent  of  operations  executed 
by  concurrent  (not  visible)  activities 

As  discussed  e,irii->r  nested  activities  must  be  serializable  at  every  level:  each  subactivity 
must  appear  indivisible  to  its  siblings  The  following  example  illustrates  this  requirement. 
Consider  the  following  tree  of  activities 


bi  b2 


Suppose  that  x  and  y  are  both  semiqueue  objects  and  consider  the  following  history 

<enq(l).x,a1> 

<ok,x,a1> 

<enq(2),y,b1> 

<ok,y,b1> 

<commil.y,b1> 

<commit,x,al> 

<deq,y.a2> 

<2.y,a2> 

<deq,x,b2> 

<1.x,b2> 

<comm)t,y,a2> 

<commit.x,b2> 

<commit,y,a> 

<commif,y,b> 

<commit,x,a> 

<commit,x,b> 

at  and  tot  enqueue  items  concurrently  at  x  and  y,  respectively,  and  then  a2  and  b?  dequeue 
items  at  y  and  x,  respectively  However,  a2  is  serializable  only  after  bt,  while  b2  is  serializable 
only  after  at.  This  implies  that  a  and  b  are  not  serializable,  since  in  any  equivalent  serial 
execution,  the  activity  that  executes  first  will  not  see  the  item  enqueued  by  the  other  activity 
Indeed,  the  deq  operation  invoked  by  a2  should  not  return  the  item  enqueued  by  bt  until  b^  is 
visible  to  a2;  i.e.,  until  bt  and  b  have  committed  At  the  point  that  a2's  deq  operation 
terminates  in  the  above  history,  a.'’  s  view  of  the  semiqueue  contains  no  items  Similarly,  the 
deq  operation  invoked  by  b2  should  not  return  the  item  enqueued  by  at  until  at  is  visible  to 
b2. 


6.3  Types  versus  Objects 

In  our  formal  model  we  fake  a  "class  like"  (Dahl  et  at  70.  Robson  81]  view  of  obiects  We 
treat  objects  as  independent  entities,  each  with  an  associated  collection  of  operations  Argus 
takes  a  different  view  treating  each  data  type  as  a  "type  manager,"  and  associating 
operations  with  the  type  rather  than  with  the  objects  This  view  is  called  "cluster  like  "  after 
the  name  of  the  module  used  to  implement  such  types 


I 


The  class  like  view  is  more  appropriate  to  distributed  systems,  in  which  the  objects  may  be 
physically  distributed  (Tor  example,  guardians  in  Argus,  used  to  implement  distnluited 
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obiects,  .uu  cLi-oS  like  We  use  clusters  Id  oui  impleuientations  to  avoni  lotioilucmy  issues 
such  as  the  distinction  between  local  and  remote  data  )  The  cluster  like  view  is  useful  for 
local  data:  for  example,  operations  that  involve  more  than  one  object  of  the  type  are  more 
conveniently  expressed  The  class  like  view,  on  the  other  hand,  provides  natural  support  for 
hierarchies  of  types  None  of  these  distinctions,  however  is  important  for  our  examples 

Operations  that  create  new  objects  are  not  naturally  associated  with  the  objects  themselves 
rather,  they  are  more  naturally  a  part  of  the  data  type  A  cluster-like  view  easily 
accommodates  creation  operations,  since  all  operations  are  associated  with  a  type  A  class 
like  view  can  be  made  to  accommodate  creation  operations  by  assuming  that  eacti  type  is 
Itself  an  object  and  by  associating  the  creation  operations  with  the  type  object. 

We  took  the  class  like  approach  in  our  formal  model:  We  assumed  that  each  type  is  itself  an 
object  with  operations  to  create  new  objects  of  the  type  We  model  the  serial  behavior  of 
creation  operations  in  the  following  way.  We  assume  that  all  objects  exist  for  all  time,  and  that 
when  a  system  starts  executing  there  is  a  sufficient  supply  in  the  system  of  each  kind  of 
object,  in  each  possible  initial  state,  to  satisfy  all  creation  operations  that  will  ever  be 
executed,  (Formally,  we  can  model  this  by  assuming  an  infinite  number  of  each  kind  of 
object )  A  creation  operation  provided  by  a  type  simply  selects  any  object  of  the  type  (m  the 
appropriate  initial  state)  that  has  not  been  previously  selected. 

The  behavioral  specification  of  a  type  must  then  describe  how  the  type  copes  with 
concurrency  and  failures  of  activities  creating  objects  We  require  that  an  object  never  be 
returned  by  a  creation  operation  more  than  once  in  an  execution:  since  our  sequential 
specification  of  creation  operations  is  non-deterministic,  this  suffices  to  ensure  that  the  type 
satisfies  all  three  local  atomicity  properties  discussed  earlier. 


6.4  Implementing  Atomic  Types  in  Argus 

In  this  section  we  discuss  how  atomic  types  can  be  implemented  in  Argus  The  section  is 
divided  into  three  parts  In  the  first,  we  discuss  the  linguistic  support  in  Argus  for 
implementing  atomic  types  In  the  second,  we  present  an  example  implementation  Finally,  in 
the  third,  we  discuss  the  strengths  and  weaknesses  of  the  approach  taken  in  Argus, 


6.4.1  Linguistic  Support 

The  mechanisms  in  Argus  have  two  important  characteristics  The  names  of  activities  are  not 
accessible  to  user  code,  and  no  user  code  runs  when  activities  complete  The  programmer 
must  rely  on  the  system  to  update  the  representations  of  objects  when  activities  complete. 
The  linguistic  support  in  Argus  consists  of  several  built  in  atomic  types,  statements  that  use 


tliose  types,  and  a  mutual  exclusion  primitive 


The  only  processing  done  by  the  Argus  system  v/hen  an  activity  completes  is  to  upd.ih?  lor-s 
and  versions  in  the  representation  of  each  object  of  a  built  m  atomic  type  Because  ot  this 
the  programmer  has  to  include  some  lower  level  atomic  objects  (and  ultimately  at  the  lov^esi 
level  some  built  in  atomic  objects)  in  the  representation  of  a  user  defined  atomic  t,pe 
However,  to  implement  types  that  permit  tughly  concurrent  use  the  programmer  must  include 
non  atomic  objects  in  addition  to  atomic  objects  Some  kind  of  synchronization  and  recovery 
IS  needed  lor  these  objects  to  cope  with  internal  concurrency  and  failures,  this  is  the  purpose 
of  the  mutual  exclusion  primitive  in  Argus  The  details  of  li.e  Argus  mechanisms  are 
described  below,  a  more  complete  descnptior:  can  be  found  in  [Liskov  et  al  83] 


6.4.1 .1  The  Type  Generator  Atomjc_varianl 

Argus  provides  several  built  in  atomic  types  and  type  generators  01  particular  interest  to  us 
in  our  examples  is  the  built  in  type  generator  atomic_variant.  The  serial  specification  o' 
atomic  variants  is  essentially  that  of  variants  m  CLU  [Liskov  et  at  81]  A  variant  type 
specification  consists  of  a  list  of  tags  and  associated  types.  The  state  of  a  variant  object 
consists  of  a  lag  and  a  value:  if  the  current  tag  of  a  variant  is  f.  then  the  type  of  the  current 
value  of  the  variant  is  the  type  associated  with  /  For  each  tag  t  m  the  type  specification,  there 
are  four  operations:  makej.  change j.  isj.  and  value J.  Makej  lakes  one  argument  of  the 
type  associated  with  the  tag  r.  and  returns  a  new  variant  object  whose  tag  is  t  and  whose  value 
is  the  argu.nent  of  the  operation  v^hangej  takes  two  arguments,  a  variant  and  an  ob;  . '  of 
the  type  associated  with  t.  and  changes  the  slate  of  the  variant  so  that  its  tag  is  t  and  its  value 
IS  the.  second  argument  of  the  operation.  Isj  takes  one  variant  argument,  and  returns  true  if 
and  only  if  the  tag  of  the  variant  is  /.  Finally,  value J  takes  one  variant  argument,  if  the  tag  of 
the  variant  is  t  then  it  returns  the  current  value,  and  otherwise  it  signals  wrong  jag  When 
only  these  operations  are  used,  atomic  variants  are  dynamic  atomic. 

Atomic  variants  are  used  in  two  ways  in  conjunction  with  other  atomic  objects,  to  make 
activities  atomic:  and  ’n  conjunction  with  non  atomic  objects  as  part  of  the  representation  of 
a  user  defined  atomic  object  In  the  latter  case,  it  may  be  possible  for  an  activity  to  gam 
access  to  an  atomic  variant  created  by  another  activity  that  h.us  aborted  or  is  still  active  For 
example,  one  activity  might  create  an  atomic  variant  and  insert  m  a  (non  atomic)  array,  a 
concurrent  activity  with  access  to  the  array  could  then  access  the  newly  created  atomic 
variant  Thus  the  ria-ej  operations,  which  create  new'  atomic  variant  objects,  require 
special  consideration  We  must  define  what  happens  to  an  atomic  variant  when  its  creator 
aborts  and  whether  concurrent  activities  can  use  an  atomic  variant  before  the  object's 
^rt-ator  has  completed 

IMS  iL'fir.es  the  makcj  operation  to  create  a  new  atomic  variant  object  whose  tag  is  t  and 
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vjtioso  value  IS  the  aiyument  to  the  operation,  this  state  is  the  ob)ec*  s  "base"  state,  and  the 
object  will  continue  to  exist  in  this  state  even  if  the  creating  activity  aborts.  (An  alternative  is 
to  have  the  object  "disappear"  when  its  creator  aborts:  our  experience  indicates  that  this 
leads  to  awkward  and  complex  programs.) 

Concuiient  use  of  a  newly  created  atomic  variant  is  limited  as  follows  The  operations  on 
atomic  variants  are  cla.ssified  as  readers  and  writers  Synchronization  of  activities  using  an 
atomic  variant  object  is  done  with  read  and  write  locks  The  usual  locking  rules  apply:  Any 
number  of  activities  can  hold  read  locks  simultaneously,  but  if  one  activity  holds  a  write  lock 
then  no  other  activity  can  hold  a  read  lock  or  a  write  lock.  Makt-j.  isj.  and  value_i  are  all 
readers,  and  changej  is  a  writer,  readers  acquire  read  locks  when  executed,  and  writers 
acquire  write  locks  By  having  the  activity  that  creates  an  atomic  vai'ant  retain  a  read  lock,  vje 
ensure  that  the  activity  will  not  observe  concurrent  use  of  the  object  by  other  activities 

6  4.1.2TheTagtest  Statement 

In  an  implementation  of  a  user-defined  atomic  type,  it  is  convenient  for  an  activity  to  be  able  to 
test  whether  it  would  have  to  wait  if  it  were  to  invoke  a  particular  operation  on  an  atomic 
variant  Argus  provides  the  tagtest  statement  as  structured  support  for  testing  and  setting 
locks  on  atomic  variants  The  use  of  the  tagtest  statement  can  violate  atomicity,  since  it 
permits  an  activity  to  observe  the  presence  of  concurrent  activities  However,  it  appears  to  be 
necessary  for  implementing  user  defined  atomic  types  using  an  implicit  program  structure. 

A  tagtest  statement  has  the  following  form;’ 
tagtest  expression 

atag_arm  {  atag_arm  } 

[ others:  body ] 
end 

where 

atag_arm  ::  =  tag_kind  name. . .  [(idn:  type_spec)  ]  :  body 

tag_kind  ::  =  tag 

I  wtag 

The  expression  must  evaluate  to  an  atomic  variant  object.  If  a  read  lock  could  be  obtained  on 
the  atomic  variant  object  by  the  activity  executing  the  statement,  then  the  tag  of  the  object  is 
matched  against  the  names  on  the  atag_arms:  if  a  matching  name  is  found.  tf>en  the  tag_kind 
on  the  arm  is  considered. 


'we  use  an  extended  BNF  lor  syntactic  descriptions,  with  the  (ollowing  conventions  |  is  used  to  separate 
altei\-.,atwer,  "[  a  j  denotes  an  optional  a.  {a}  *  deno\es  a  sequence  lero  or  mo*e  a  s.  and  "a.  "  denotes  a 
list  of  on^-  or  more  a  s  sop.irnird  by  commas 
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II  the  lag_kin{i  is  tag  a  read  lock  is  obtained  on  the  obiect  and  the  match  is  complete  II  the 
lag^kmd  is  wtag  and  the  activity  can  obtain  a  write  lock  on  the  object,  then  a  write  lock  is 
obtained  and  the  match  is  complete,  in  all  other  cases  the  match  is  incomplete 

II  a  complete  match  is  not  found  or  the  activity  could  not  obtain  a  read  lock,  then  the  body  in 
the  others  arm.  il  present,  is  executed,  il  there  is  no  others  arm.  the  fagtest  statement 
terminates 

When  a  complete  match  is  lound.  il  a  declaration  (idn.  iypp_spcc)  appears  on  the  matching 
arm,  the  value  component  ol  the  obiect  is  assigned  to  the  local  variable  idn.  The  body  on  the 
matching  arm  is  then  executed,  lOn,  if  declared  is  dehned  only  in  that  body  The  entire 
matching  process,  including  testing  and  acquisition  of  locks  is  indivisible 


6. 4. t. 3  Mutual  Exclusion 

Argus  provides  the  built  in  ty'’  ?  generator  mutex  and  the  seize  statement  to  enable 
implementations  to  cope  with  concurrency  among  executions  of  operations.  Mutex  and 
seize  can  be  used  to  ensure  mutual  exclusion  among  regions  of  code  executed  by 
concurrent  operations:  thus,  for  example,  implementations  can  prevent  interference  among 
concurrently  executing  operations  by  forcing  them  to  run  serially. 

Mutex  obiects  are  mutable  containers  tor  mlormation  The  type  generator  mutex  has  a  single 
parameter,  which  is  the  type  of  the  contained  object.  Mutex  types  provide  operations  to 
create  and  decompose  mutex  obiects.  The  create  operation  takes  a  single  argument  of  the 
parameter  type  and  creates  a  new  mutex  object  containing  the  argument  object.  The 
get_va!ue  operation  extracts  and  returns  the  contained  obiect  from  its  mutex  argument; 
following  the  conventions  of  Argus,  the  expression  "mutex[t]$get_value(m)"  is  usually 
written  "m  value". 

Mutexes  are  used  primarily  to  provide  mutual  exclusion  on  non  atomic  shared  data  Argus 
provides  the  seize  statement,  which  allows  a  sequence  of  statements  to  be  executed  by  an 
activity  while  the  activity  is  in  exclusive  possession  of  a  mutex  obiect  The  seize  statement 
has  the  following  form: 

seize  expression  do  body  end 

The  expression  must  evaluate  to  a  mutex  object  After  evaluating  the  expression,  the 
executing  activity  attempts  to  gam  possession  of  the  resulting  mutex  obiect.  Only  one  activity 
may  have  possession  of  a  mutex  object  at  one  time:  thus,  an  activity  may  be  forced  to  wait 
when  It  attempts  to  gam  possession  Once  the  activity  gains  possession,  the  body  of  the 
seize  statement  is  executed  Termination  of  the  body  causes  possession  of  the  mutex  object 
to  be  released.  If  several  processes  are  waiting  for  possession  of  the  same  mutex  object, 
possession  will  be  awarded  fairly,  in  the  sense  that  as  long  as  no  process  retains  possession 
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forever,  every  waiting  process  will  eventually  gam  possession. 

An  implementation  of  an  operation  often  has  a  precondition  that  must  be  true  before  the 
operation  can  be  executed.  Sometimes  it  is  necessary  to  gam  possession  of  mutex  objects 
simply  to  test  the  precondition:  if  the  precondition  is  false,  the  operation  must  wait  It  is 
important  to  release  possession  of  mutex  objects  while  waiting  particularly  if  some  other 
operation  that  requires  possession  of  ttie  mutex  objects  must  be  executed  for  the 
precondition  to  become  true  ArguS  provides  the  pause  statement  for  this  purpose.  It  may 
be  executed  only  inside  the  body  of  a  seize  statement.  When  a  process  executes  pause,  the 
mutex  object  seized  by  the  closest  enclosing  seize  statement  is  released  and  the  process  is 
blocked  tor  a  system  determined  time  When  the  process  is  unblocked,  it  regains  possession 
of  the  mutex  object  released  by  the  pause  statement.  v;aiting  if  necessary,  and  then 
continues  execution  with  the  statement  following  the  pause. 

Activities  m  Argus  never  fail  while  in  possession  of  a  mutex  object  unless  the  containing 
guardian  crashes  When  such  a  crash  occurs,  the  states  of  the  objects  m  the  guardian  are 
restored  from  stable  storage  A  discussion  of  the  interactions  between  implementations  of 
atomic  types  and  stable  storage  in  Argus  can  be  found  m  (Weihl  &  Liskov  82]  In  this  chapter 
and  the  next  we  will  assume  that  an  activity  in  possession  of  a  mutex  object  executes  the  body 
of  the  seize  statement  correctly,  and  does  not  abort  until  after  it  has  released  possession  of 
the  mutex 


6.4.2  Implementation  of  the  Semiqueue  Type 

Our  first  example  is  an  implementation  of  the  semiqueue  type.  The  serial  specification  of  a 
semiqueue  object  was  presented  in  Figure  2-3;  the  corresponding  informal  specification  of 
the  semiqueue  type  is  presented  in  Figure  6- 1  Semiqueues  are  similar  to  queues,  except  that 
enqueued  items  are  not  necessarily  dequeued  in  first  in  first  out  order.  Instead,  the  deq 
operation  makes  a  non  deterministic  choice  of  an  item  to  remove  and  return. 

As  noted  in  Sections  4  4  1  and  5.4  2.  semiqueues  place  few  constraints  on  concurrency.  Two 
enq  operations  commute  with  each  other,  as  do  an  enq  and  a  deq  operation  or  two  deq 
operations  as  long  as  they  involve  different  items  Thus,  many  different  activities  can  enq 
concurrently  or  deq  concurrently.  Furthermore,  one  activity  can  enq  while  another  deq's, 
provided  only  that  the  deq  not  return  the  newly  enq'd  item  Dynamic  atomicity  permits  some 
additional  concurrency  as  well  one  activity  can  enq  an  item  while  another  deq's  the  same 
item  as  long  as  at  least  one  committed  activity  has  enqueued  the  same  item. 

An  implementation  of  the  semiqueue  data  type  appears  in  Figure  6  3.  The  plan  of  this 
implementation  is  to  keep  the  enqueued  items  in  a  regular  (non  atomic)  array.  This  array  can 
be  used  by  concurrent  activities,  but  it  is  enclosed  in  a  mutex  object  to  control  internal 


data  type  soiiiKiuoiiclilein  type]  is  c'c-.iic.  eiiq  dcq 

%  A  semiqueue  is  like  a  bag  (or  multiset)  ol  items,  semiqueuelitem]  is  dynamic  atomic  if 
%  Item  IS  dynamic  atomic 

create  =  proc  ()  returns  (semiqueue) 

°o  Returns  a  new  empty  semiqueue. 

enq  =  proc  (q:  semiqueue,  i:  item) 

%  Adds  I  to  Q 

deq  =  proc  (q  semiqueue)  returns  (item) 

°/D  If  q  IS  non  empty,  chooses  some  element  o!  q.  removes  it  from  q.  and  returns  it. 

Figure  6-1  :lnformal  specification  of  the  data  type  semiqueue 

concurrency.  All  modification  and  reading  of  the  array  occurs  inside  a  seize  statement  on 
this  containing  mutex  object.  An  Informal  specification  of  arrays  appears  in  Figure  6  2. 

To  determine  the  status  of  each  item  in  the  array,  we  associate  with  each  item  an  atomic 
object  that  tells  the  status  of  activities  that  inserted  or  deleted  that  item  For  this  purpose  we 
use  the  built-in  atomic  type  atomic_variant  (described  in  the  previous  section). 

The  semiqueue  operations  are  implemented  as  follows:  The  create  operation  simply  creates  a 
new  empty  array  and  places  it  inside  a  new  mutex  object.  The  enq  operation  associates  a 
new  atomic  variant  object  with  the  argument  item:  this  atomic  variant  will  have  tag 
"enqueued"  if  the  calling  activity  commits  later,  and  tag  "dequeued"  If  it  aborts  Then  enq 
seizes  the  mutex  and  adds  the  new  atomic  variant  to  the  contained  array. 

The  deq  operation  seizes  the  mutex  and  then  searches  the  array  for  an  item  it  can  dequeue:  If 
an  atomic  variant  has  tag  "enqueued"  and  the  activity  that  called  deq  can  get  a  write  lock  on 
It.  the  contained  item  is  selected  and  returned  after  changing  the  variant's  lag  to  "dequeued" 
If  no  suitable  atomic  variant  is  found,  pause  is  executed  (releasing  the  mutex)  and  later  the 
search  is  retried. 

Proper  synchronization  of  activities  using  a  semiqueue  is  achieved  by  using  the  qitems  in  the 
buffer  An  enq  operation  need  not  wait  for  any  other  activity  to  complete.  It  simply  creates  a 
new  qtiem  and  adds  it  to  the  array.  Of  course,  it  may  have  to  wait  for  another  operation  to 
release  the  mutex  obiect  before  adding  the  q'tem  to  the  array,  but  this  delay  should  be 
relatively  short.  A  deq  must  wait  until  some  activity  that  executed  an  enq  operation  commits 
relative  to  the  activity  that  invoked  deq:  thus  it  searches  for  a  qitem  with  tag  "enqueued  "  that 
it  can  write. 

The  qitems  are  also  used  to  achieve  proper  recovery  for  activities  using  a  semiqueue.  Since 


92 


data  type  atray[l  type]  is  new,  size,  empty  fetch  store,  addli  addi,  remh,  reml,  elements 

%  Arrays  are  extensible:  they  can  grow  and  shrink  They  may  be  viewed  as  partial  mappings 
%  liom  integers  to  ohiects  of  type  t.  with  the  restriction  that  an  array  is  always  defined  on  a 
%  connected  interval  of  integers  The  state  of  an  array  a  can  be  modeled  with  two  compo- 
%  nents  an  integer  a  low.  called  the  low  bound,  and  a  sequence  a  eiis  ol  objects  o(  type  t, 

%  called  the  elements  An  array  a  is  empty  it  a  e/fs  is  the  empty  sequence,  and  is  otherwise 
%  defined  on  integers  irom  a  low  to  a  low  +  |a  e/tsl-l ,  where  |a  e/ts|  is  the  length  of  a  ells  We 
%  say  that  an  integer  i  is  rn  bounds  for  an  array  a  if  a  is  defined  on  /  If  s  is  a  sequence,  we 
%  use  s(i)  to  denote  the  ith  element  of  s  (where  s(i )  is  the  first  element  ol  s) 

new  =  proc  ()  returns  (array[t]) 

%  Returns  a  new  empty  array  with  low  bound  1 . 

Size  =  proc  (a  array[t])  returns  (int) 

%  Returns  [a  ells]. 

empty  =  proc  (a  array[t])  returns  (bool) 

%  Returns  true  if  and  only  if  |a  e/fs|  =  0. 

fetch  =  proc  (a  arrayft],  i  int)  returns  (t)  signals  (bounds) 

%  If  a  IS  defined  on  /,  then  returns  a  e/ts(i-a  low  +  1 ),  otherwise  signals  bounds 

store  =  proc  (a  array(t].  i  int.  x:  t)  signals  (bounds) 

%  If  a  IS  defined  on  r,  then  changes  a  e/fs(/-a  low  +  1)  to  x,  otherwise  signals  bounds. 

addh  =  proc  (a;  array[t],  x;  t) 

%  Changes  a, efts  to  a.elisH*. 

addi  =  proc  (a  array(t].  x:  t) 

%  Changes  a  elts  to  x||a  e//s.  and  changes  a  low  to  a  low-t.  Decrementing 
%  a  low  keeps  the  indexes  of  the  previously  existing  elements  the  same. 

remh  =  proc  (a  array[t])  returns  (t)  signals  (bounds) 

%  Changes  a  ells  by  removing  the  last  element  m  the  sequence;  signals  bounds  if  |a.e/fs|  =  0. 
reml  =  proc  (a  array]!])  returns  (t)  signals  (bounds) 

%  Changes  a  elts  by  removing  the  last  element  in  the  sequence,  and  increments  a. low.  signals 
%  bounds  if  |a  e/ts|  =  0  Incrementing  a  low  keeps  the  indexes  ol  the  previously  existing 
%  elements  the  same 

elements  =  iter  (a:  array[l])  yields  (t) 

%  Yields  the  elements  of  a  elts  m  order  from  the  first  to  the  last. 

Figure  6-2:lnformai  specification  of  the  data  type  array. 
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Figure  6-3:lniplicit  implemenlation  of  the  data  type  semiqueue 


semiqueue  =  clusterfitem  type]  is  create,  enq,  deq 

qitem  =  atomic_varianl[enqueued:  item, 
dequeued:  null] 

butter  =  array[qitem] 

rep  =  mutex[buffer] 

create  =  proc  ()  returns  (cvf) 

return(rep$creale{buffer$new{))) 
end  create 

enq  =  proc  {q  cvt,  i:  item) 

qi:  qitem  :  =  qitem$makc_dequeued(nil)  %  dequeued  if  activity  aborts 
qitem$change_enqueued(qi,  i)  %  enqueued  it  activity  commits 

seize  q  do 

b:  buffer  :=  q. value 

buffer$addh(b,  qi)  %  add  new  qitem  to  buffer 

end 
end  enq 

deq  =  proc  (q:  cvt)  returns  (item) 

cleanupfq)  %  cleanup  should  be  called  less  frequently 
seize  q  do 

b:  buffer ;  =  q.value 
while  true  do 

for  qi:  qitem  in  bu(fer$elements(b)  do 

tagtest  qi  %  see  if  item  can  be  dequeued  by  this  activity 

wtag  enqueued  (i:  item):  qitem$change_dequeued(qi,nil) 

return(i) 

end 

end 

pause 

end 

end 
end  deq 


i 
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the  array  m  the  mutex  is  not  atomic,  changes  to  the  array  made  by  activities  that  abort  later 
are  not  undone.  This  means  that  a  deq  operation  cannot  simply  remove  a  qitem  from  the 
array  since  this  change  could  not  be  undone  if  the  calling  activity  later  aborted  Instead,  a 
deq  operation  changes  the  state  of  a  qiiem,  the  atomicity  of  qilems  ensures  proper  recovery 
for  this  modification.  If  the  calling  activity  later  commits  to  the  top  level,  the  qitem  will  have 
tag  "dequeued"  permanently  Such  qiiems.  which  are  also  generated  by  enq  operations 
called  by  activities  that  later  abort,  have  no  effect  on  later  operations  Leaving  them  in  the 
array  wastes  storage,  so  the  internal  procedure  cleanup,  called  by  deq.  removes  them  from 
the  low  end  of  the  array  (Of  course,  a  more  realistic  implementation  v;ould  call  cleanup  only 
occasionally  ) 

Note  that  cieani^p  cannot  run  m  the  calling  activity  If  the  calling  activity  had  previously 
executed  a  deq  operation  that  Je.;  is  visible  to  a  later  operation  executed  by  the  same 
activity  Instead  ciea^-r  funs  as  an  independent  activity  This  activity  will  only  be  able  to 
lock  qitenis  that  are  not  be>ng  used  b,  an>  active  activities,  thus  it  will  not  remove  any  qitems 
that  could  affect  later  operations 


6.4.3  Remarks 

The  implementation  of  the  S''iiii(;,,e..e  !,pe  m  the  previous  section  illustrates  the  general 
strategy  used  to  implement  a  use-  def'''i-.'!  atomic  type  m  Argus  The  representation  of  a 
user-defined  atomic  type  typically  consists  of  a  mutex  obiect  containing  a  non  atomic 
collection  (e  g  .  an  array)  of  atomic  obiects  (typically  atomic  variants)  Greater  concurrency 
among  activities  using  the  type  is  achieved  by  introducing  atomic  objects  only  at  the  lowest 
level  of  the  representation. 

The  implementation  in  the  previous  section  also  illustrates  a  number  of  limitations  of  the 
expressive  power  of  the  implicit  approach  supported  by  Argus 

First,  the  implementation  of  deq  is  relatively  inefficient  since  m  the  worst  case  it  takes  time 
proportional  to  the  size  of  the  representation  of  the  semiqueue  There  is  no  obvious  way  to 
improve  the  efficiency  of  this  implementation  The  activity  that  executes  an  operation  is 
implicit,  so  there  is  no  way  to  structure  the  representation  of  an  object  based  on  the  activities 
that  enqueued  or  dequeued  an  Hem 

Second,  scheduling  of  deq  operations  is  accomplished  using  busy  waiting  The  system  has 
very  little  information  on  which  to  base  scheduling  decisions  implying  that  an  activity  is  likely 
to  be  awakened  when  it  is  unable  to  complete  the  operation,  and  also  that  an  activity  may  be 
unlikely  to  be  awakened  very  soon  after  the  precondition  for  the  operation  becomes  true. 


Finally,  the  programmer  has  no  control  over  when  the  representation  of  an  object  gets 
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updated  by  the  system  as  activities  commit  and  abort  In  Argus,  the  system  updates  built  in 
atomic  objects  automatically  when  activities  complete,  and  does  so  at  arbitrary  times.  The 
tollowing  example  illustrates  the  problems  that  can  result  Suppose  that  we  want  to 
implement  the  semiqueue  type  with  the  following  additional  constraint  If  there  is  only  one 
dequeuing  activity  at  a  time  and  dequeuing  activities  do  not  abort  then  items  enqueued  by  a 
single  activity  should  be  dequeued  m  the  order  in  which  they  were  enqueued  This  constraint 
IS  not  satisfied  by  the  implementation  presented  above  Suppose  that  activity  A  has  enqueued 
two  Items,  X  and  Y,  in  that  order,  and  that  activity  B  starts  to  execute  a  deq  operation.  If  A 
commits  after  B  has  examined  the  first  qiiorn  (containing  X)  in  the  representation  of  the 
semiqueue  and  before  B  has  examined  the  second,  the  di-q  operation  will  return  Y. 

It  seems  impossible  to  modify  the  implementation  of  semiqueue  presented  above  to  satisfy 
this  additional  constraint  given  the  semantics  of  Argus  Suppose  deq  has  found  an  item  that 
can  be  dequeued.  There  is  no  v,ray  to  fell  whether  some  other  item  v/as  enqueued  by  the 
same  activity.  If  we  impose  the  additional  restriction  on  the  system  that  commits  and  aborts 
appear  to  be  instantaneous  (so  if  an  activity  has  committed  at  one  atomjc_ variant  then  it  has 
committed  at  any  others  that  it  touched),  then  we  can  modify  deq  to  search  backwards 
through  the  representation  and  to  return  the  last  available  item  that  it  finds  (Or  to  search 
forwards  until  it  finds  one  available  item,  and  then  to  search  backwards  from  there  )  The 
resulting  implementation  satisfies  the  additional  constraint  on  semiqueues 

This  example  illustrates  that  the  programmer  does  not  have  complete  control  over  all  events 
that  affect  the  representation  of  an  object.  Commit  and  abort  events  involving  lower-level 
objects  are  controlled  by  the  system,  and  can  occur  asynchronously  This  asynchrony  is 
visible  to  the  programmer,  and  can  affect  the  correctness  of  an  implementation. 

In  the  next  chapter  we  will  present  an  alternative  approach  that  avoids  the  problems 
discussed  above. 


Chapter  Seven 


Support  for  an  Explicit  Approach 


In  this  chapter  we  discuss  an  explicit  approach  (or  implementing  atomic  types,  in  winch  the 
programmer  supplies  code  that  is  tun  when  activities  complete  to  update  the  representations 
of  obiects.  We  begin  m  Section  7.1  by  describing  extensions  to  Argus  to  support  the  explicit 
approach  Then,  in  Section  7  2.  we  present  an  example  implementation  to  illustrate  the 
approach  Finally,  m  Section  7  3  we  compare  the  implicit  and  explicit  approaches 

7.1  Linguistic  Support 

We  present  the  language  constructs  as  additions  to  Argus  We  do  not  intend  this  to  be  a 
complete  language  proposal,  rather,  it  is  a  vehicle  for  presenting  examples  using  an  explicit 
approach  The  examples  will  serve  both  to  illustrate  how  implementations  of  atomic  types  can 
be  constructed  using  an  explicit  approach,  and  as  a  basis  for  comparing  the  explicit  and 
implicit  approaches. 

We  extend  Argus  in  three  ways  First,  we  add  a  new  built-in  data  type,  aid.  to  rep'esent 
names  of  activities  Second,  we  extend  the  existing  module  for  implementing  abstract  data 
types  (the  cluster)  to  provide  the  implementation  of  an  operation  with  access  to  the  name  of 
the  activity  that  invoked  it,  and  to  permit  easy  identification  to  the  system  of  the  code  to  be  run 
when  activities  commit  and  abort.  Third,  we  add  a  queuing/signalling  mechanism  designed 
to  support  efficient  synchronization  of  activities. 

An  informal  specification  of  the  type  aid  appears  in  Figure  7-1  Note  that  no  operations  are 
provided  to  create  new  aids  While  we  will  allov;  an  implementation  of  an  atomic  type  explicit 
access  to  the  aid  of  an  activity  that  invokes  one  of  the  type's  operations,  we  follow  Argus  in 
implicitly  associating  aids  with  processes  Thus,  the  system  automatically  creates  new  aids 
whenever  an  existing  activity  executes  the  enter  statement  to  create  subactivities  or  nested 
top  level  activities  and  associates  ttie  nevy  aids  with  the  corresponding  processes  Also  note 
that  the  set  of  operations  provided  by  the  type  aid  is  not  complete,  we  have  included  only 
those  that  we  need  for  our  examples,  and  expect  that  others  would  be  needed  for  general 
use 

We  extend  clusters  in  two  ways  First,  a  routine  m  a  cluster  that  implements  an  operation  of 
the  defined  type  can  have  two  intedace  specifications  The  external  specification 
corresponds  to  the  interface  specification  of  the  operation  m  the  type's  specification  The 
internal  specification  differs  from  the  external  specification  in  that  it  has  an  additional  implicit 


djt.i  lypc  aid  IS  iiau-iil  ami'siors  piopci.aiicoslurs.  top,  equal 

paren!  '  proc  (a  aid)  returns  (aid)  signals  (lop) 
ill  u, ms  a  s  paienl  signals  lop  it  a  has  no  parent 

ancosiors  =  iter  (a  aid)  yields  (aid) 

“n  Yields  me  ancesl.Hs  ot  a  including  a  itsell  m  root  to  leaf  order, 
piopor  anceslufs  =  iter  (a  aid)  yields  (aid) 

%  Y,e,ds  the  piotx'T  ancestors  ot  a  (i  e  ,  not  including  a  itself)  in  root  to  leaf  order, 
top  =  pioc  (a  aid)  returns  (bool) 

\  ifei.jms  true  if  a  is  a  lop  level  activity,  otherwise  returns  false 
equal  =  proc  (at  aP  aid)  returns  (true) 

%  (returns  true  if  a  i  and  ar  nanie  the  same  activity,  otherwise  returns  false. 

Figu  re  7- 1  -intormal  specification  of  the  data  type  aid. 

argument.  This  implicit  argument  must  appear  as  the  first  argument  in  the  argument  list  of  the 
routine,  and  has  type  aid  Thus  for  example,  an  operation  with  external  specification 
op  =  proc  (x1:  t1, ...) ... 
might  have  internal  specification 

op  =  proc  (a:  aid,  x1 :  tl ,  .. ) ... 

The  identifier  used  to  declare  the  implicit  argument  may  be  chosen  at  the  convenience  of  the 
programmer.  When  a  routine  with  distinct  internal  and  external  specifications  is  invoked,  the 
implicit  argument  is  assigned  the  value  of  the  aid  of  the  invoking  activity,  and  the  other 
arguments  are  assigned  the  values  of  the  corresponding  actuals. 

Second  a  duster  may  supply  two  additional  operations,  called  commit  and  abort.  We  call 
these  special  operations  compie'  on  operations  Their  interfaces  are  as  follows; 
commit  =  proc  (a  aid  x  rep)  signals  (lailure(st  ring)) 

abort  =  proc  (a  aid  X  rep)  signals  (failure(string)) 

These  operations  are  intended  to  be  called  by  the  system  (say.  with  arguments  a  and  x)  when 
an  activity  a  that  used  tire  object  represented  by  x  commits  or  aborts  To  let  the  system  know 
that  an  activity  has  used  an  cbiect  the  routines  inside  a  cluster  may  call  the  special  procedure 
register,  which  has  the  following  interlace 

register  =  proc  (a  aid  x  rep)  signals  (completed) 

An  invocation  of  register  will  signal  compipted  if  the  activity  named  by  the  first  aigument  has 
already  committed  or  aborted  Otherwise  the  invocation  will  return  Sometime  after  the 
activity  a  completes  the  system  will  invoke  the  appropriate  completion  operation  defined  in 
the  cluster  (commit  if  the  activity  commits  abort  if  the  activity  aborts)  with  arguments  a  and 
X  I)  the  completion  operation  signals  failure,  the  system  will  try  again  at  some  future  time  If  a 
committing  activity  is  a  subacfivily  of  another  activity,  and  the  invocation  of  the  commit 
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operation  terminates  normally,  the  system  will  also  register  the  activity's  parent  on  the  '.anu? 
obiect,  thus  when  the  parent  completes,  the  appropriate  completion  operation  will  again  be 
invoked  (Similarly,  if  the  parent  commits  and  its  commit  operation  terminates  normally  the 
system  will  register  its  parent  on  the  same  obiect,  and  so  on  until  a  top  level  activity  is 
reached.) 

We  will  use  the  mutex  type  and  the  seize  statement  in  Argus  to  cope  with  internal 
concurrency  As  m  the  previous  chapter,  we  assume  that  activities  do  not  fail  when  in 
possession  of  a  mutex  object 

Finally  we  add  the  built  in  data  type  aclion_queue  to  allow  operations  to  wait  for  necessary 
preconditions.  An  informal  specification  of  the  operations  provided  by  action  queue 
appears  in  Figure  7  2,  We  also  provide  the  block  statement  to  allow  an  activity  to  wait  on  an 
action_queue  The  block  statement  has  the  following  form; 
block  expri  on  expr2 

The  first  expression  must  evaluate  to  an  aid.  and  the  second  to  an  action_queue  The 
block  statement  can  appear  only  within  a  seize  statement  When  executed,  it  blocks  tne 
executing  process  on  the  specified  action_queue  on  behalf  of  the  specified  aid,  and 
releases  the  mutex  obiect  seized  by  the  closest  enclosing  seize  statement. 

A  process  blocked  on  an  ac*'on_queue  is  m  one  of  two  states;  asleep  or  waiting.  When  a 
process  executes  a  blr  statement,  it  is  initially  asleep.  An  asleep  process  on  an 
action_queue  changes  to  the  v^aitmg  state  when  some  other  process  executes  the  notily  or 
wake  operation  on  the  acfion_queue.  A  process  in  the  waiting  state  attempts  to  regain 
possession  of  the  mutex  object  that  was  released  when  the  process  blocked,  and  is 
unblocked  as  soon  as  it  regains  possession. 


7.2  Implementalion  of  the  Semiqueue  Type 

In  this  section  we  present  an  implementation  of  the  semiquoue  type  using  the  linguistic 
constructs  described  in  the  previous  section  An  informal  specification  of  semiqueues 
appeared  in  Figure  6  1  The  implementation  appears  in  Figure  7-4  It  uses  the  type  generator 
log',  an  informal  specification  of  logs  appears  in  Figure  7-3. 

The  representation  of  a  semiqueue  consists  of  three  components  enclosed  in  a  mutex  obiect 
The  components  are  committed .  which  represents  thu  items  known  to  be  in  the  semiqueue 
(they  have  been  enqueued  by  activities  that  have  committed  to  the  top  level,  and  they  have 
not  been  dequeued),  logs,  which  is  a  collection  of  summary  information  about  the  operations 
executed  by  active  activities  and  pending,  which  is  an  activity  queue  used  for  blocking  dog 
operations  that  cannot  find  an  item  to  dequeue  The  mutex  object  is  used  to  prevent 


100 


data  type  action  queuc  is  t  ioaic  nohly,  wake  empty 

%  A  process  can  add  itself  to  an  aclion  queue  by  execulmy  ttie  block  statement,  specifying 
%  an  aid  on  wliose  betialt  it  wisties  to  wait  A  processor!  an  action  queue  is  in  one  ot  two 
%  states  asleep  or  wai/ing  A  wailing  process  will  be  unblocked  as  soon  as  it  can  regain 
%  possession  ot  the  mutex  object  released  wtien  it  blocked  Ai'  action  queue  is  empty  it 
%  and  only  it  no  processes  asleep  or  waiting  are  b'oeked  on  it 

create  =  proc  ()  returns  (action  queuc) 

%  Returns  a  new.  empty  action  queue 

notify  =  proc  (q  action  queuc.  a  aid) 

%  Changes  all  asleep  processes  on  g  waiting  on  behalf  of  siblings  of  a  or  their  descendants  to 
%  waiting:  all  top-level  activities  are  considered  to  be  siblings  of  a  top-level  activity. 

wake  =  proc  (q  action  queue) 

%  Changes  all  asleep  processes  on  q  to  waiting. 

empty  =  proc  (q  action  queuc)  returns  (bool) 

%  Ret.  'OS  false  it  any  process,  asleep  or  waiting,  is  blocked  on  q,  otherwise  returns  true. 

Figure  7-2:lnlormal  specification  of  the  data  type  action_queue 


interference  among  concurrently  executing  operations  on  the  same  semiqueue  by  forcing 
them. to  run  serially. 

The  summary  for  an  activity  consists  of  two  parts:  enq.  which  represents  the  items  enqueued 
by  the  activity  (or  its  committed  descendants)  and  not  subsequently  dequeued;  and  deq. 
which  represents  the  items  dequeued  by  the  activity  (or  its  committed  descendants),  and 
contains  sufficient  information  to  be  able  to  "undo"  the  deq  operations  if  the  activity  aborts. 

The  implementation  of  enq  works  as  follows:  It  finds  the  summary  record  for  the  invoking 
activity  by  calling  the  internal  procedure  hndjog  It  then  adds  the  item  to  be  enqueued  to  the 
list  of  Items  enqueued  by  the  activity,  registers  the  invoking  activity  and  the  semiqueue  object 
(so  the  appropriate  completion  operation  will  be  invoked  by  the  system  when  the  activity 
completes),  and  returns  The  mechanism  used  for  enq  operations  is  like  an  intentions  list:  a 
record  of  the  operation  is  kept,  but  the  operation  only  becomes  visible  to  the  activity's  siblings 
when  the  activity  commits  If  the  activity  aborts,  the  record  of  the  operation  is  discarded. 

The  implementation  of  deq  is  more  complex  It  first  looks  for  an  item  to  dequeue  by  calling 
the  internal  procedure  /md  c'isf  Fma  vii>t  searches  the  committed  items  and  the  intentions 
lists  for  the  calling  activity  and  its  ancestors  looking  for  a  non  empty  list  The  lists  searched 
by  Und_eiist  contain  the  enqueued  items  that  are  visible  to  the  calling  activity  and  that  have 
not  yet  been  dequeued  If  no  list  is  found  by  lind_elist.  deq  blocks  on  the  queue  in  the 
representation  of  the  semiqueue  and  tries  again  when  some  activity  that  used  the  semiqueue 
becomes  visible  to  the  calling  activity  If  a  non  empty  list  is  found  by  lind_eiisl.  deq  removes 
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data  type  log[t:  type]  is  create,  letch,  store,  delete,  ancestors 

%  A  ob)OCt  maps  aids  to  t  objects. 

create  =  proc  ()  returns  (log[t]) 

%  Returns  a  new.  empty  log. 

letch  =  proc  (I  log[t].  a:  aid)  returns  (t)  signals  (notjound) 

%  Returns  the  f  object  associated  with  a  in  /.  signalling  notjound  if  a  is  not  bound  in  I. 

store  =  proc  (I:  log[t],  a:  aid,  x;  t) 

%  Binds  a  to  X  in  /. 

delete  =  proc  (I:  log[t],  a:  aid) 

%  Unbinds  a  in  /. 

root2leal  =  iter  (I:  log[t],  a:  aid)  yields  (aid.  t) 

%  Yields  each  ancer.tc  ol  a  (including  a  itsell)  with  its  associated  binding,  if  it  is  bound  in  f; 

%  items  are  yielded  in  oot-fo-leaf  order. 

leaf2root  =  iter  (I.  iog[t].  a:  aid)  yields  (aid,  t) 

%  Yields  each  ancestor  ol  a  (including  a  itself)  with  its  associated  binding,  if  it  is  bound  in  /; 

%  items  are  yielded  in  leaf-to-root  order. 

Figu  re  7-3:lnformal  specification  of  the  data  type  log. 

the  first  item  from  the  list  and  creates  an  undo  record  containing  that  item  and  the  list.  Next,  if 
the  item  dequeued  was  not  enqueued  by  the  invoking  activity  (or  one  of  its  committed 
descendants),  the  undo  record  is  added  to  the  summary  information  for  the  activity.  (If  the 
same  activity  enqueued  and  then  dequeued  an  item,  there  is  no  need  to  remember  either 
operation;  the  net  effect  on  the  semiqueue  will  be  the  same  regardless  of  whether  the  activity 
commits  or  aborts.)  Finally,  the  invoking  activity  and  the  semiqueue  are  registered,  and  the 
item  to  be  dequeued  is  returned. 

The  mechanism  used  for  deq  operations  is  like  an  undo  log:  If  the  invoking  activity  aborts,  the 
information  in  the  undo  records  is  used  to  put  the  item  back  in  the  list  from  which  it  was 
removed,  effectively  "undoing"  the  operation. 

The  abort  routine  is  simple:  It  undoes  the  deq  operations  executed  by  the  aborting  activity 
and  its  committed  descendants  by  putting  the  dequeued  items  back  in  the  lists  from  which 
they  were  removed,  and  then  discards  the  summary  (including  the  intentions  list  of  enqueued 
items)  for  the  aborting  activity.  Finally,  if  any  deq  operations  were  undone,  the  abort  routine 
unblocks  any  pending  deq  operations,  since  the  items  that  were  returned  from  the  aborting 
activity's  undo  list  might  now  be  visible  to  the  pending  operations. 


The  commit  routine  merges  the  summary  for  the  committing  activity  with  that  for  its  parent. 
The  activity's  list  of  enqueued  items  is  simply  appended  to  its  parent's  list.  The  undo 
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Figure  7-4:Explicit  implementation  of  the  data  type  semiqueue. 


semiqueue  =  cluster  [item:  type]  is  create,  erx),  deq 

undo  =  structfi:  item,  %  item  returned  by  deq  op. 

deletedjrom:  elist]  %  elist  it  was  removed  from. 

elist  =  array  [item]  %  intentions  list  lor  enq's.  and  list 

%  of  fully  committed  enq'd  items. 

dlist  =  array[undo]  %  undo  log  lor  deq‘8. 

summary  =  struct[enq:  elist,  %  summary  of  operations  executed  by 

deq :  dlist]  %  a  single  activity. 

aq  =  action_queue 

components  =  struct[committed:  elist,  %  committed  items  in  senoiqueue. 

logs:  log[summary],  %  summaries  for  all  activities, 
pending:  aq]  %  pending  deq  ops. 

rep  =  mutex  [components] 

%  rep  invariant; 

%  for  each  activity  a.  and  for  each  undo  record  u  in  rep.value.logs[a].deq,  either 
%  u.deletedjrom  =  rep.value.committed.  or  there  exists  a  proper  ancestor  a’  of  a  such 
%  that  u.deletedjrom  =  rep.value.logs[a’].enq 

create  =  proc  ()  returns  (cvt) 

return(rep$create(components$(committed:elist$new(), 

logs:  Iog[summary]$create0. 
pending;  aq$create()))) 

end  create 

%  external  spec;  enq  z  proc  (q:  cvt,  i;  item) 
enq  a  proc(a;  aid,  q;  cvt,  i:  item) 
seize  q  do 

s:  summary :  a  find_log(q.value.logs,  a) 
eiist$addh(8.enq,  i) 
register(a,  q) 
end 
end  enq 
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Figure  7-4:  (continued) 


%  external  spec:  deq  =  proc  (q:  cvt)  returns  (item) 
deq  =  proc  (a:  aid.  q:  cvt)  returns  (item) 
seize  q  do 

while  true  do 

visible;  ciist :  =  lind_elist(q.value.a) 

except  when  none,  block  a  on  q.vatue. pending  %  pause 
continue  %  and  retry 


end 

u:  undo  :  =  undoS(i:  elistSreml(visible).  deleted Jrom:  visible) 
s;  summary :  s  findJog(q.value.logs,  a) 

If  u.deleted_from  ~  *  s.enq 

then  dlist$addh(s.deq.  u)  end'lo  else  operations  cancel  each  other 
register(a,  q) 
return(u.i) 
end 


end 
end  deq 


%  gets  the  summary  for  a  from  logs. 

find  Jog  =  proc  (logs:  log[summary],  a:  aid)  returns  (summary) 
return(logs(a]) 

except  when  nut  Jound;  s:  summary :  s  summary${enq;  elist$new(), 

deq:  dlist$new()} 

logs[a] :  s  s 
return(s) 
end 

end  find  Jog 

%  finds  a  non  empty  elist  visible  to  a  (i.e.,  either  committed,  or  belonging  to  an  ancestor 
%  of  a).  If  q. committed  is  non-empty  it  is  returned.  Signals  if  no  non-empty  elist  is  found. 
firKf_elist  s  proc  (c.  components,  a.  aid)  returns  (elist)  signals  (none) 
if  elist$size(c.committed)  ~  s  0  then  return(c.committed)  end 
for  anc:  aid.  s;  summary  in  log[s'jmmary]Sroot2leaf(c.logs,  a)  do 
if  elist$size(s.enq)  ~  =  0  then  return(s  enq)  end 
end 

signal  rrane 
end  find.elist 


i 
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Figure  7-4;  (continued) 

commit  =  proc  (a:  aid,  q.  rep)  signals  (lailure<string)) 
seize  q  do 

qv;  components ;  >  q.value 
I;  log[summary] :  =  qv.logs 
as:  summary :  =  l[a] 

except  when  notjound:  return  end 
log[summary]Sdelete(i.  a) 
ps:  summary ;  =  findJog(l,  aidSparent(a)) 

except  when  top:  merge_enq(qv.committed.  as.erKt) 

if  elist$size<as.enq)  ~  =  0  then  aq$wake(qv. pending)  end 
return 

end 

merge_enq(ps.enq,  as.enq) 
merge_deq(ps.  as.deq) 

it  elist$size(as.enq)  -  =  0  then  aq$notify(qv  pending,  a)  end 

end 

end  commit 

abort  =  proc  (a;  aid,  q:  rep)  signals  (failure(slring)) 
seize  q  do 

as:  summary ;  s  q.value. logsfa] 

except  when  notjound:  return  end 
log[summary]Sdelete(q.value.logs,  a) 
for  u:  undo  in  dlist$elements(as.deq)  do 
elistSaddh(u.deletedJrom,  u.i) 
end 

if  diist$size(as.deq)  ~  s  o  then  aq$wake(q.value.pending)  end 

end 

end  abort 

%  appends  (in  order)  items  in  from  onto  to. 
merge.enq  s  proc  (to:  elist,  from:  elist) 
for  i:  item  in  elist$elements(from)  do 
eli8t$addh(to,  i) 

end 

end  merge.enq 
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Figure  7*4:  (continued) 

%  appends  (in  order)  undos  in  from  onto  to  deq.  ignoring  those  undos  u 
%  with  u.detetedjrom  =  to  enq  (such  deq’s  have  committed  to  the 
%  level  of  the  corresponding  enq,  so  both  operations  can  be  forgotten). 
merge_deq  =  proc  (to.  summary,  from:  dlist) 
for  u:  undo  in  dlist$elements(from)  do 
if  u.delotcdjrom  ■■  =  to.enq 
then  dlist$addh(to  deq,  u) 
end 
end 

end  merge.deq 
end  semiqueue 
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information  for  dcq  operations  is  similarly  appended,  except  that  records  for  items  enqueued 
by  the  parent  are  discarded  from  the  ut\do  log.  (The  operations  effectively  cancel  each  other 
in  this  case.)  In  the  case  of  a  committing  top  level  activity,  the  tentatively  enqueued  items  are 
appended  to  the  list  of  committed  items,  and  the  undo  log  is  discarded.  Finally,  if  any  items 
enqueued  by  the  committing  activity  were  added  to  its  parent's  intentions  list,  the  commit 
routine  unblocks  pending  deq  operations  invoked  by  activities  to  which  the  committing 
activity  is  now  visible. 

When  a  blocked  deq  operation  is  unblocked,  there  is  no  guarantee  that  it  will  be  able  to 
execute.  For  example,  there  may  be  several  pending  deq  operations  unblocked  by  the  same 
completing  activity,  but  it  is  possible  that  only  one  will  actually  be  able  to  dequeue  an  item. 
Thus,  the  deq  operation  loops  after  blocking,  and  may  block  again  if  it  still  finds  no  items 
available  for  it  to  dequeue. 

7.3  Remarks 

In  this  section  we  discuss  the  relative  merits  of  the  implicit  and  explicit  approaches.  We  begin 
in  Section  7.3.1  by  summarizing  the  conclusions  to  be  drawn  from  the  examples,  including 
those  presented  in  the  appendix.  Next,  in  Section  7.3.2,  we  compare  the  two  approaches. 
Finally,  in  Section  7.3.3,  we  discuss  related  work. 

7.3.1  Summary  of  Examples 

First,  in  Section  7.3. 1.1  we  discuss  the  two  implementations  of  the  semiqueue  type.  Next,  we 
summarize  the  conclusions  to  be  drawn  from  the  three  examples  in  the  appendix.  Two  of 
those  examples  are  implementations  of  the  map  type,  one  using  an  implicit  approach  and  the 
other  an  explicit  approach.  The  third  is  an  implementation  of  the  bankjsccount  type.  We 
discuss  the  implementations  of  map  in  Section  7.3. 1.2,  and  the  implementation  of 
bank_account  in  Section  7.3. 1.3. 

7.3. 1.1  Implementations  of  the  Semiqueue  Type 

The  explicit  implementation  of  the  semiqueue  type  has  a  number  of  advantages  over  the 
implicit  implementation.  First,  the  implementation  of  the  deq  operation  in  the  explicit 
implementation  is  more  efficient  than  in  the  implicit  implementation.  In  the  implicit 
implementation  the  deq  operation  takes  time  proportional  to  the  size  of  the  representation  of 
its  semiqueue  argument  (in  the  worst  case);  in  the  explicit  implementation  the  deq  operation 
takes  time  proportional  to  the  number  of  ancestors  of  the  calling  activity  (again  in  the  worst 
case).  This  difference  arises  because  the  explicit  implementation  has  access  to  the  names  of 
invoking  activities. 
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Second,  the  semiqueue  type  cannot  be  implemented  in  Argus  to  satisfy  additional  properties 
like  the  restriction  that  items  enqueued  by  a  single  activity  be  dequeued  in  the  order  in  which 
they  are  enqueued:  the  explicit  mechanism  presented  here  does  not  suffer  from  this  limitation 
The  problem  with  Argus  is  that  the  system  does  not  update  the  states  of  all  built  m  atomic 
objects  instantaneously,  so  it  is  possible  for  one  activity  to  see  that  another  activity  has 
committed  at  one  built-in  object,  and  later  to  see  that  the  activity  still  holds  a  lock  on  another 
built-in  object.  It  is  possible  to  change  the  semantics  of  Argus  to  avoid  this  problem 
However,  it  might  be  expensive  for  the  system  to  guarantee  that  commits  and  aborts  appear 
instantaneous  in  a  distributed  system.  In  addition,  even  with  this  additional  guarantee,  it  can 
be  difficult  to  implement  the  "fifo"-like  restriction  on  semiqueues. 

Third,  the  implicit  implementation  of  the  semiqueue  type  uses  busy-waiting  to  schedule  deq 
operations,  while  the  explicit  implementation  uses  a  signalling  mechanism.  The  signalling 
mechanism  can  be  significantly  more  efficient  than  busy-waiting:  In  the  implicit 
implementation,  the  system  has  very  little  information  on  which  to  base  scheduling  decisions, 
and  is  quite  likely  to  awaken  a  pending  operation  when  the  operation  cannot  proceed,  and  not 
to  awaken  a  pending  operation  when  in  fact  it  can  proceed.  In  the  explicit  implementation,  a 
pending  deq  operation  is  awakened  only  if  an  activity  that  enqueued  some  items  becomes 
visible  to  the  activity  waiting  to  deq,  or  if  an  activity  that  dequeued  some  items  aborts,  making 
those  items  available  for  other  activities  to  dequeue. 

Finally,  the  implicit  implementation  requires  a  "cleanup"  routine  to  keep  the  size  of  the 
representation  of  a  semiqueue  from  increasing  forever;  the  explicit  implementation 
accomplishes  the  same  effect  with  the  user-supplied  completion  operations,  and  does  it  more 
efficiently  since  it  is  possible  to  tell  from  the  arguments  to  the  completion  operation  exactly 
what  information  needs  to  be  deleted  from  the  representation  and  when  it  needs  to  be 
deleted. 

7.3.1 .2  Implementations  of  the  Map  Type 

Maps  are  like  associative  memories,  binding  uids  to  other  objects.  A  map  provides  three 
operations:  insert,  which  adds  a  new  binding  to  the  map;  delete,  which  deletes  a  binding  from 
the  map;  and  lookup,  which  retrieves  the  binding  for  a  specified  uid  from  the  map. 

Both  implementations  of  the  map  type  in  the  appendix  use  a  two-phase  locking  protocol, 
based  on  the  state  machine  LOCK  described  in  Chapter  5.  They  illustrate  how  a  locking 
protocol  that  chooses  locks  based  on  the  results  of  operations  as  well  as  their  arguments  can 
be  implemented. 

The  two  implementations  provide  the  same  level  of  concurrency.  In  addition,  they  use  similar 
representations  for  maps:  both  represent  a  map  using  a  non-atomic  table  protected  by  a 
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mutex:  tables  are  like  maps,  except  that  they  are  not  atomic  The  implementations  differ  in 
several  ways,  however. 

First,  the  implicit  implementation  requires  an  internal  "cleanup"  routine  (like  the  cleanup 
routine  in  the  implicit  implementation  of  semiqueues)  to  keep  the  representation  from  growing 
too  large.  The  explicit  implementation  uses  the  completion  operations  to  update  the 
representation  of  a  map  as  activities  complete,  avoiding  this  kind  of  periodic  "garbage 
collection"  of  the  representation. 

Second,  the  implicit  implementation  uses  busy  waiting  for  scheduling,  while  the  explicit 
implementation  uses  aclion_queues.  Separate  queues  are  used  for  each  uid.  with  the  result 
that  a  pending  operation  on  a  uid  will  be  awakened  only  if  an  activity  that  used  the  same  uid 
aborts  c'  becomes  visible  to  the  activity  that  invoked  the  operation  (i.e.,  commits  to  their  least 
common  ancestor).  A  queue  is  stored  for  a  uid  only  if  an  operation  on  the  uid  that  was 
invoked  by  an  active  activity  was  forced  to  wait.  If  conflicts  causing  operations  to  wait  are 
relatively  rare,  then  the  number  of  queues  stored  should  be  small. 

Third,  the  explicit  implementation  keeps  track  explicitly  of  the  uids  used  by  an  activity;  this 
effect  is  achieved  in  the  implicit  implementation  by  the  fact  that  the  system  keeps  track  of  the 
built  in  atomic  objects  used  by  each  activity. 

The  explicit  implementation  appears  significantly  more  complex  than  the  implicit 
implementation.  It  contains  156  lines  of  code,  while  the  implicit  implementation  contains  64 
lines  of  code.  Some  of  the  extra  code  (31  lines)  is  needed  for  managing  queues.  Much  of  the 
rest  (65  lines)  is  needed  to  manage  information  and  perform  tasks  that  are  handled 
automatically  by  the  system  in  the  implicit  approach,  ror  example,  the  completion  operations 
themselves,  and  keeping  track  of  the  uids  used  by  each  activity. 


7.3.1 .3  Implementation  of  the  8ank_account  Type 

A  bank  account  provide  three  operations:  deposit,  which  adds  a  specified  amount  to  the 
account;  withdraw,  which  removes  a  specified  amount  from  the  account,  signalling 
insuflicientjunds  if  the  balance  is  too  low;  and  balance,  which  returns  the  current  balance  in 
the  account.  The  explicit  implementation  in  the  appendix  illustrates  how  an  implementation  of 
an  atomic  type  can  provide  more  concurrency  than  can  be  achieved  with  two-phase  locking. 
It  also  serves  to  illustrate  further  the  greater  expressive  power  and,  in  some  cases,  ease  of 
use.  of  the  explicit  approach;  The  lack  of  access  to  the  names  of  invoking  activities  in  the 
implicit  approach  makes  it  difficult,  if  not  impossible,  to  construct  an  implicit  implementation 
that  permits  comparable  levels  of  concurrency. 
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7.3.2  Comparison 

We  base  our  comparison  of  the  implicit  and  explicit  approaches  on  the  two  implementations 
of  the  semiqueue  type  presented  above,  and  on  the  implementations  of  the  map  and 
bank_account  types  presented  in  the  appendix. 

The  explicit  approach  described  earlier  in  this  chapter  is  strictly  more  powerful  than  the 
implicit  approach  in  Argus.  It  extends  the  Argus  approach  in  three  ways:  implementations  of 
atomic  types  have  explicit  access  to  the  names  of  invoking  activities;  the  programmer  can 
supply  code  that  is  run  when  activities  complete  to  update  the  representations  of  objects;  and 
implementations  can  explicitly  awaken  a  pending  operation  when  it  might  be  able  to  proceed, 
rather  than  using  busy  waiting  to  perform  scheduling. 

By  permitting  implementations  to  access  the  name  of  the  activity  that  invokes  an  operation, 
we  achieve  greater  flexibility  in  structuring  the  representations  of  objects,  and  avoid  some  of 
the  limitations  of  the  implicit  approach.  For  example,  the  deq  operation  in  the  implicit 
implementation  of  the  semiqueue  type  takes  time  proportional  to  the  size  of  the 
representation  of  its  semiqueue  argument  (in  the  worst  case).  In  the  explicit  implementation, 
the  deq  operation  takes  time  proportional  to  the  number  of  ancestors  of  the  calling  activity 
(again  in  the  worst  case). 

Similarly,  it  is  impossible  using  the  implicit  approach  to  satisfy  the  constraint  on  semiqueues 
that,  as  long  as  at  most  one  activity  dequeues  items  at  a  time  and  that  activity  does  not  abort, 
items  enqueued  by  a  single  activity  should  be  dequeued  in  the  order  in  which  they  were 
enqueued.  The  reader  can  easily  verify  that  the  explicit  implementation  of  the  semiqueue  type 
satisfies  this  constraint. 

Achieving  this  flexibility  in  structuring  representations  appears  to  require  access  to  the  names 
of  invoking  activities,  but  does  not  require  the  use  of  user  supplied  completion  operations. 
We  could  provide  a  "query"  operation  on  aid  objects,  permitting  an  implementation  to  find 
out  from  the  system  whether  a  given  activity  is  still  active,  and  if  not,  whether  it  has  committed 
or  aborted.  An  implementation  could  periodically  check  the  status  of  active  activities,  and 
update  the  representation  of  an  object  appropriately  when  told  that  an  activity  has  completed. 
In  this  way  we  could  achieve  much  of  the  effect  of  user-supplied  completion  operations, 
without  having  them  executed  automatically  by  the  system. 

While  user-supplied  completion  operations  are  not  needed  for  flexibility  in  structuring 
representations,  they  may  be  necessary  for  achieving  efficient  scheduling  of  operations.  The 
implicit  approach  in  Argus  uses  busy-waiting  to  schedule  operations:  as  illustrated  by  the 
implementations  of  the  semiqueue  and  map  types,  the  queuing  mechanism  in  the  explicit 
approach  presented  here  permits  much  more  control  over  scheduling  of  operations.  The 
mechanism  relies  on  user-supplied  completion  operations  to  awaken  blocked  operations 
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explicitly  It  is  not  clear  whether  comparable  control  over  scheduling  can  be  achieved  without 
user-supplied  completion  operations. 

The  explicit  implementations  that  we  have  presented  are  obviously  more  complex  than  the 
implicit  ones.  Much  of  this  complexity  arises  from  the  need  to  represent  explicitly  certain 
kinds  of  information  that  are  handled  automatically  by  the  system  in  the  implicit  approach. 
For  example,  in  the  explicit  implementation  of  the  map  type  in  the  appendix,  we  explicitly 
represent  the  uids  used  by  an  activity:  in  the  implicit  implementation,  this  is  not  necessary 
because  the  system  keeps  track  of  the  built  in  atomic  objects  used  by  activities. 

Some  of  the  complexity,  however,  arises  out  of  the  desire  for  more  efficient  and  more 
concurrent  implementations.  Some  of  the  information  that  is  handled  automatically  by  the 
system  in  the  implicit  approach  may  be  more  efficiently  used  when  structured  differently  (e  g., 
compare  the  two  semiqueue  implementations);  As  discussed  above,  the  explicit  approach,  by 
permitting  implementations  to  access  the  names  of  invoking  activities,  provides  control  over 
this  structure,  while  the  implicit  approach  does  not.  In  addition,  the  management  of  queues 
introduces  complexity,  but  also  permits  much  more  efficient  scheduling. 

More  work  may  be  required  of  the  programmer  in  the  explicit  approach,  since  it  may  be 
necessary  to  supply  completion  operations.  However,  in  the  implicit  approach  it  is  frequently 
necessary  to  provide  an  internal  operation  that  compacts  the  representations  of  objects  (e  g., 
the  cleanup  routine  in  the  implicit  implementation  of  the  semiqueue  type);  this  kind  of  interna) 
garbage  collection  is  not  needed  in  explicit  implementations. 

In  addition,  the  explicit  approach  does  not  require  linguistic  support  that  is  specific  to  a 
particular  local  atomicity  property.  The  tagtest  statement  in  Argus  is  designed  to  support 
implementations  of  dynamic  atomic  types,  and  provides  little  if  any  help  in  building 
implementations  of  static  atomic  types.  In  contrast,  the  explicit  structure  presented  above,  by 
permitting  explicit  access  to  aids,  provides  the  programmer  with  tools  that  can  be  used  for 
implementing  static  atomic  types  as  well  as  dynamic  atomic  types.  Hybrid  atomic  types  can 
also  be  implemented  using  the  explicit  structure,  although  for  efficient  management  of  old 
versions  it  might  be  useful  to  add  explicit  "initiate"  operations  for  read  only  activities. 

Neither  the  linguistic  support  in  Argus,  nor  the  extensions  we  presented  earlier  in  this  chapter, 
supports  optimistic  implementations.  It  appears  relatively  easy  to  do  so  using  an  explicit 
approach,  simply  by  allowing  programmers  to  supply  an  explicit  "pre  commit"  operation  for 
objects  to  vote  on  whether  to  allow  an  activity  to  commit.  It  appears  very  difficult  to  extend  an 
implicit  approach  to  permit  optimistic  implementations. 

The  use  of  mutual  exclusion  to  control  internal  concurrency  is  just  a  simple  way  of  making  the 
implementations  of  operations  "atomic,”  by  forcing  them  to  run  serially.  A  more  general 
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approach  is  to  use  atomic  actions,  making  each  execution  of  an  operation  a  top  level  activity 
This  approach  appears  viable,  however,  only  if  implementations  have  access  to  the  names  of 
invoking  activities  In  an  implicit  structure,  certain  steps  in  the  implementation  of  an  operation 
(e  g.,  operations  on  lower-level  atomic  objects)  must  be  executed  on  behalf  of  the  invoking 
activity,  yet  there  is  no  way  for  a  process  to  act  on  behalf  of  two  activities  at  the  same  time. 
Even  in  an  explicit  structure,  this  approach  may  have  difficulties  It  is  not  clear  whether  a 
queuing  mechanism  comparable  to  our  action_queues  can  be  designed  to  work  with  top- 
level  activities  instead  of  with  seize  statements. 

In  summary,  the  expressive  power  of  the  implicit  approach  is  limited  in  several  ways. 
However,  implementations  using  an  explicit  approach  appear  more  complex  It  is  not  clear 
whether  an  intermediate  approach  can  be  found  that  provides  the  efficiency  of  the  explicit 
approach  but  avoids  some  of  the  complexity. 


7.3.3  Related  Work 

Some  recent  work  at  CMU  by  Spector  and  Schwarz  [Schwarz  &  Spector  82]  has  coni  ..r 
how  to  build  "atomic  objects."  Spector  and  Schwarz  ignore  recovery,  however,  and  iw-us 
only  on  locking  implementations.  They  appear  to  suggest  that  the  system  should  manage 
"lock  tables"  automatically,  but  do  not  describe  in  detail  how  the  programmer  can  describe 
the  set  of  lock  modes  and  their  conflict  relationships  to  the  system.  In  addition,  it  is 
sometimes  difficult  for  an  operation  to  tell  in  advance  what  kind  of  lock  it  will  need;  for 
example,  in  implementations  of  the  map  type,  an  insert  operation  will  need  a  different  kind  of 
lock  depending  on  whether  it  terminates  normally  or  signals.  This  indicates  that  an  automatic 
locking  mechanism  might  be  difficult  to  use. 

Work  at  Newcastle  on  recovery  blocks  [Anderson  et  at.  78,  Anderson  &  Lee  79,  Verhofstad  76] 
investigated  recovery  techniques  for  building  user-defined  data  types.  While  concurrency 
was  not  considered,  alternative  program  structures  were  explored  The  inclusive  recovery 
scheme  in  [Anderson  ef  al  78]  is  similar  to  our  implicit  approach,  while  their  disjoint  recovery 
scheme  is  similar  to  our  explicit  approach  The  authors  of  [Anderson  et  al  78,  Anderson  & 
Lee  79]  note  that  the  inclusive  scheme  provides  limited  control  over  recovery  and  can  be  less 
efficient  than  the  disjoint  scheme,  but  that  implementations  in  the  disjoint  scheme  can  be 
more  complex  than  those  in  the  inclusive  scheme  These  conclusions  are  similar  to  our 
conclusions  about  the  implicit  and  explicit  approaches  for  implementing  atomic  types. 

Allchin  [Allchin  &  McKendry  83,  Allchin  83]  has  also  investigated  "atomic  objects."  He  has 
focused  on  the  implicit  approach,  attempting  to  make  the  system  do  as  much  of  the  work  as 
possible  As  we  have  discussed  above,  this  approach  provides  limited  expressive  power 
One  interesting  mechanism  that  he  proposes  is  a  queuing  mechanism  for  an  implicit  scheme: 
He  associates  one  queue  with  each  object.  An  activity  can  wait  on  a  queue,  and  will  be 


awakened  wtien  another  activity  that  used  the  same  object  becomes  visible  to  it  However,  he 
does  not  consider  examples  like  the  map  type  (illustrated  in  the  appendix  of  this  dissertation, 
and  discussed  in  Section  7  3  1).  for  which  it  may  be  important  to  have  finer  control  over 
scheduling.  In  particular,  it  is  important  in  the  implementation  of  map  in  Section  A, 2  to  be 
able  to  discard  queues  that  are  no  longer  needed  for  pending  operations  This  appears 
impossible  in  the  implicit  queuing  mechanism  proposed  by  Allchin. 


Chapter  Eight 


Summary  and  Conclusions 


8.1  Summary 

Atomicity  is  a  useful  organizational  concept  (or  reducing  the  complexify  of  a  concurrent 
system.  If  activities  are  atomic,  concurrency  can  be  ignored  when  checking  that  the  state  of 
the  system  remains  consistent.  In  this  dissertation  we  have  explored  how  to  specify  and 
implement  "atomic  types,"  which  support  atomicity  of  activities. 

One  of  the  most  important  contributions  of  this  dissertation  is  a  specification  framework  that 
permits  the  behavioral  specification  of  an  object  to  be  derived  systematically  from  a 
specification  of  its  serial  behavior.  In  addition,  our  framework  permits  the  programmer  of  an 
individual  activity  to  ignore  how  atomicity  is  achieved,  and  to  focus  on  the  serial  behavior  of 
each  object. 

In  studying  what  it  means  for  an  object  to  be  atomic,  wo  generalized  existing  work  on 
concurrency  control  in  three  important  ways: 

Our  definition  of  atomicity  is  based  on  an  explicit  specification  of  the  desired 
behavior  for  the  objects  shared  by  activities. 

•  Our  definition  of  atomicity  encompasses  both  serializability  and  recoverability. 

-  We  identify  /oca/  properties  of  individual  objects  that  ensure  global  atomicity  of 
activities. 

Our  focus  on  local  properties  appears  to  be  unique  A  few  papers  (e  g.,  [Bernstein  ef  at. 
81,  Korth  81a,  Beeri  et  at  83])  have  considered  using  specifications  to  increase  concurrency, 
and  at  least  one  paper  [Lynch  83]  has  considered  recovery  in  addition  to  synchronization. 
However,  we  know  of  no  other  work  focusing  on  local  properties  of  objects,  or  dealing  with 
more  than  one  of  the  above  three  issues. 

We  also  presented  a  novel  two  phase  locking  protocol,  and  verified  its  correctness.  Our 
presentation  and  analysis  of  the  protocol,  unlike  published  descriptions  of  existing  protocols, 
cover  recovery  as  wel>  as  synchronization.  The  protocol  extends  existing  protocols  in  two 
ways:  It  permits  operations  to  be  partial  and  non  deterministic,  and  it  permits  the  results  of 
operations,  as  well  as  their  arguments,  to  be  used  in  synchronizing  activities. 

Finally,  we  presented  several  examples  of  implementations  of  atomic  types,  illustrating  how 
existing  techniques  for  synchronizing  and  recovering  activities  can  be  extended  to  achieve 
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greater  concurrency  In  addition,  we  presented  two  different  linguistic  mechanisms.  The 
mechanism  in  Argus  is  clearly  limited  in  expressive  power:  the  alternative  that  we  explore, 
while  more  powerful,  may  also  be  harder  'n  use. 


6.2  Conclusions  and  Further  Work 

Each  0*  the  three  local  atomicity  properties  defined  in  this  dissertation  characterizes  the 
operation  of  a  large  class  of  protocols.  Each  defines  limits  on  the  concurrency  among 
activities  that  can  be  permitted  by  types.  In  addition,  each  is  optimal,  in  the  sense  that  no 
more  concurrency  can  be  permitted  without  violating  atomicity.  The  three  properties  do  not 
characterize  all  protocols,  however  It  might  be  worth  investigating  how  to  extend  other 
protocols  (see.  e  g  ,  (Silberschatz  &  Kedem  80.  Kung  &  Robinson  81j)  to  cope  with  user- 
defined  operations 

CXir  optimality  results  indicate  that,  without  further  constraints,  objects  satisfying  different 
local  atomicity  properties  (e  g.,  dynamic  atomicity  and  static  atomicity)  cannot  be  used  in  the 
same  system.  As  systems  grow  and  existing  systems  are  interconnected,  it  will  become 
necessary  to  cope  with  connec.  g  systems  that  use  different  protocols.  Existing  protocols 
will  need  to  be  extended  so  that  the  interactions  among  different  protocols  can  be  handled 
gracefully. 

At  the  moment  it  does  not  appear  that  any  one  local  atomicity  properly  is  clearly  "best,"  in  the 
sense  of  providing  better  performance  than  any  other.  This  means  that  a  system  designer 
must  choose  which  local  atomicity  property  to  use  in  a  system.  More  experimentation  is 
needed  to  determine  the  Kinds  of  applications  for  which  each  local  property  provides  good 
performance. 

It  is  clear  from  the  example  implementations  that  we  have  presented  that  implementing  an 
atomic  type  is  a  difficult  tasK.  One  of  the  reasons  for  the  complexity  of  these  implementations 
is  the  interaction  between  synchronization  and  recovery.  The  traditional  approach  to 
analyzing  atomicity  in  database  systems  is  to  assume  that  synchronization  and  recovery  are 
provided  by  separate  modules  in  the  implementation.  However,  our  presentation  and 
verification  of  the  locking  protocol  in  Chapter  5  should  make  it  clear  that  synchronization  and 
recovery  can  interact  in  subtle  ways,  particularly  when  we  consider  operations  other  than 
reads  and  writes.  Implementations  of  atomic  types  need  to  be  explored  further  in  an  attempt 
to  develop  a  better  understanding  of  how  they  should  be  structured. 

Of  the  two  program  structures  that  we  have  studied,  the  explicit  structure  is  the  more  general, 
but  requires  more  work  on  the  part  of  the  programmer.  It  seems  unlikely  that  general  support 
could  be  designed  that  would  significantly  reduce  the  complexity  of  implementations  and  at 
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the  same  time  provide  the  expressive  power  o(  the  explicit  structure  studied  here  On  the 
other  hand,  it  may  be  that  specialized  support  can  be  developed  lor  particular  implementation 
strategies,  such  as  locking.  Experimental  work  is  also  needed  to  evaluate  the  need  lor  certain 
kinds  ol  expressive  power;  it  may  be  that  the  expressive  power  limitations  ol  the  mechanisms 
in  Argus  are  not  important  lor  many  applications. 

Perhaps  the  biggest  problem  with  the  Argus  mechanism  is  its  lack  ol  Ilexibility;  It  appears 
dillicult  to  use  lor  implementing  types  other  than  dynamic  atomic  types.  A  more  flexible 
mechanism  would  be  prelerable,  if  only  because  it  would  permit  experimentation  with 
different  local  atomicity  properties. 

Atomic  types  are  clearly  useful  in  many  applications  for  supporting  atomicity.  However,  it  is 
not  clear  how  often  the  programmer  will  need  to  take  on  the  job  of  implementing 
synchronization  and  recovery.  It  may  be  that  the  performance  demands  of  most  applications 
can  be  satisfied  without  basing  synchronization  on  the  specifications  of  objects,  or  that  only  a 
lew  types  in  a  system  need  to  provide  this  extra  concurrency.  It  is  clear  that  this  extra 
concurrency  will  be  provided  rarely  as  long  as  it  is  so  difficult  to  construct  an  implementation 
that  provides  it. 

A  hard  problem  that  we  have  not  considered  is  how  to  test  and  debug  a  concurrent  system. 
Activities  using  atomic  types,  as  well  as  implementations  of  atomic  types,  will  need  to  be 
tested  and  debugged.  It  may  be  that  the  needs  of  testing  and  debugging  will  also  influence 
the  choice  of  mechanisms  for  implementing  an  atomic  type. 

We  have  barely  touched  on  the  problem  of  ensuring  "reliable"  operation  of  a  system.  Among 
the  possible  requirements  that  an  application  might  make  are  that  systems  remain  available, 
that  information  not  be  lost,  and  that  activities  make  progress.  Existing  protocols  for  meeting 
these  requirements  need  to  be  extended  to  cope  with  user  defined  operations,  and  the 
interactions  of  these  extensions  with  implementations  of  atomic  types  need  to  be  explored. 
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Appendix  A 

Example  implementations 


In  this  appendix  we  present  three  example  implementations  of  dynamic  atomic  types.  The 
first,  in  Section  A  1,  is  an  implementation  of  a  map  data  type  using  an  implicit  structure  The 
second,  in  Section  A. 2,  is  an  implementation  of  the  same  data  type  using  an  explicit  structure. 
The  third,  in  Section  A  3,  is  an  implementation  of  a  bank  account  data  type  using  an  explicit 
structure.  This  implementation  illustrates  how  a  data  type  that  permits  more  concurrency 
than  allowed  by  locking  can  be  implemented.  Finally,  in  Section  A. 4,  we  discuss  the 
conclusions  to  be  drawn  from  the  examples. 


A.1  Implicit  Implementation  of  the  Map  Type 

In  this  section  we  present  an  implementation  of  the  map  type  using  an  implicit  structure.  An 
informal  specification  of  the  map  type  appears  in  Figure  A-1.  Maps  are  like  associative 
memories,  binding  uids  to  other  objects.  In  different  maps,  the  uids  can  be  bound  to  different 
types  of  objects.  The  type  of  the  bound  object  for  a  particular  map  type  is  given  by  the 
parameter  type  v/ype. 

Maps  permit  substantial  concurrency.  Insert,  delete,  and  lookup  operations  involving 
different  uids  commute,  and  so  can  be  used  by  concurrent  activities.  Not  much  concurrency, 
however,  is  possible  among  operations  involving  the  same  uid.  If  we  classify  insert  and  delete 
operations  that  terminate  normally  (rather  than  signalling)  as  writers,  and  all  other  operations 
as  readers,  we  see  that  readers  commute  with  each  other,  and  that  a  writer  does  not  commute 
v/ith  any  other  operation  involving  the  same  uid.  For  example,  if  an  activity  inserts  a  binding 
for  a  uid,  concurrent  activities  cannot  execute  any  operations  involving  that  uid,  although  the 
lookup  operation  could  be  performed  by  a  concurrent  activity  if  the  insert  had  signalled 
duplicate.  Similarly,  if  a  lookup  executed  by  an  activity  terminates  normally,  a  concurrent 
activity  cannot  delete  the  same  uid,  while  if  a  lookup  executed  by  an  activity  signals 
notjound,  a  concurrent  activity  cannot  insert  the  same  uid. 

The  concurrency  analysis  above  is  the  basis  for  the  implementation  of  map  in  Figure  A  2.  The 
strategy  employed  in  this  implementation  is  similar  to  that  used  in  the  implementation  of  the 
semiqueue  type  presented  earlier.  A  map  is  represented  using  a  regular  (non  atomic)  table. 
Tables  provide  the  same  operations  as  maps,  with  the  same  serial  specification,  and  in 
addition  an  iterator  pairs,  with  the  following  specification; 
pairs  =  iter  (t:  tablefv./pe])  yields  (uid,  vtype) 
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data  type  map[vtypo  type]  is  create,  insert,  delete,  lookup 

%  Maps  are  like  associative  memories,  binding  uids  to  vtype  obiects;  map[vfype)  is  dynamic 
%  atomic  it  vtype  is  dynamic  atomic. 

create  =  proc  ()  returns  (map) 

%  Returns  a  new.  eniply  map  (one  containing  no  bindings). 

insert  =  proc  (m  map.  u:  uid.  v:  vlype)  signals  (duplicate) 

%  It  u  IS  not  bound  in  m.  binds  u  to  v  m  m.  otherwise  signals  duplicate 

delete  =  proc  (m  map,  u;  uid)  signals  (notjound) 

%  It  u  IS  bound  in  m,  unbinds  u  in  m;  otherwise  signals  notjound. 

lookup  =  proc  (m:  map,  u;  uid)  returns  (vtype)  signals  (notjound) 

%  It  u  IS  bound  in  m,  returns  the  associated  vtype  object;  otherwise  signals  notjound. 

Figure  A*1 :  Intormal  specification  of  the  data  type  map. 

Pairs  yields  all  pairs  (u.v)  such  that  u  is  bound  to  v  in  /,  Unlike  maps,  however,  tables  are  not 
atomic.  Since  the  table  is  not  atomic,  changes  to  it  made  by  activities  that  later  abort  are  not 
undone;  thus,  the  table  maps  uids  to  atomic  variant  objects  rather  than  directly  to  the 
corresponding  vtype  objects.  In  addition,  the  table  is  enclosed  in  a  mutex  object  to  handle 
internal  concurrency. 

The  implementation  of  map  also  uses  the  Argus  built-in  type  null.  Null  is  generally  used  as  a 
kind  of  "place  filler"  in  a  variant  type  when  the  tag  contains  all  necessary  information.  Null 
has  exactly  one  immutable  object,  represented  by  the  literal  nil. 

The  implementations  of  insert,  delete,  and  lookup  are  all  similar.  Each  seizes  the  mutex,  and 
then  calls  the  internal  procedure  Undjstatus  to  obtain  the  atomic  variant  associated  with  a 
given  uid.  Next,  if  the  status  object  can  be  locked  appropriately,  its  lag  is  checked,  and  then 
either  information  is  returned  about  the  binding  or  the  status  object  is  modified  to  reflect  a 
change  in  the  binding.  (Of  course,  if  the  invoking  activity  later  aborts,  this  modification  to  the 
status  object  will  be  undone.)  If  the  status  object  cannot  be  locked  appropriately,  the 
operation  pauses,  releasing  possession  of  the  mutex.  When  possession  is  regained,  the 
operation  tries  again. 

findjstatus  gives  the  illusion  that  a  status  object  exists  for  all  uids  If  the  uid  is  bound  to  a 
status  object,  that  one  is  returned.  Otherwise,  the  uid  is  not  bound  by  the  map.  so  findjstatus 
creates  a  new  status  object  with  base  state  "absent."  binds  the  uid  to  it  in  the  table,  and 
returns  it. 

When  an  activity  that  deleted  a  uid  from  the  map  commits,  the  status  object  associated  with 
the  uid  will  have  tag  "absent."  Such  status  objects  waste  space:  The  same  information  can 
be  represented  by  the  absence  of  a  binding  for  the  uid  in  the  table  The  internal  procedure 
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Figure  A-2;  Implicit  implementation  ot  the  data  type  map 

map  =  clustef[viype  type]  is  create,  insert,  delete,  lookup 

status  =  atomlc_variant[present:  vtype, 
absent:  null] 

log  =  lable[status]  %  maps  uids  to  status  objects. 

rep  =  mutex[log] 

create  =  proc  ()  returns  (cvt) 
return(rep$create(log$create())) 
end  create 

insert  =  proc  (m:  cvt,  u:  uid,  v;  vtype)  signals  (duplicate) 
seize  m  do 

while  true  do 

s:  status  :  =  find_status(m. value,  u) 
tagtest  s 

tag  present:  signal  duplicate 

wtag  absent:  status$change_presenl(s,  v) 

return 

end 

pause  %  couldn't  lock  s:  wait  and  try  again. 

end 

end 

end  insert 


delete  =  proc  (m:  cvt,  u:  uid)  signals  (not .found) 
seize  m  do 

while  true  do 

s:  status  :  =  find.statusfm. value,  u) 

tagtest  s 

wtag  present:  slatus$change_absent(s,  nil) 
return 

tag  absent:  signal  not.found 
end 

pause  %  couldn't  lock  s;  wait  and  try  again. 

end 

end 

end  delete 


f 

i 

f 


128 


Figure  A- 2:  (continued) 

lookup  =  proc  (m.  cvt,  u:  uid)  returns  (vtype)  signals  (notjound) 
seize  m  do 

while  true  do 

tagtest  find_status{m  value,  o) 

tag  present  (v:  vtype):  return  (v) 
tag  absent,  signal  nof_found 

end 

pause  %  couldn’t  lock  s.  wail  and  try  again. 

end 

end 

end  lookup 

find_status  =  proc  (I;  log,  u:  uid)  returns  (status) 
cieanup(l) 

return  (log$lookup(l,  u)) 
except  when  not_lound: 

s  status  :  =  slatus$make_absenl(nil) 
log$insert(l,  u,  s) 
return  (s) 
end 

end  find_status 

cleanup  =  proc  (I.  log) 
enter  topaction 

for  u:  uid,  s:  status  in  log$pairs(l)  do 

tagtest  s 

wtag  absent:  log$delete(l,  u) 

end 

end 

end 

end  cleanup 
end  map 
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cic.inup.  called  by  find^si.ilus.  finds  and  leinoves  sucli  bindings  from  the  table 

Note  that  cleanup  runs  as  an  independent  activity,  and  removes  only  those  status  objects  that 
are  not  being  used  by  any  active  activity.  Cleanup  cannot  remove  status  objects  with  tag 
"absent"  that  are  being  read  by  active  activities  these  status  objects  must  be  retained  to 
prevent  the  "phantom  record"  problen.  jEswaren  el  ai  76).  in  which  one  activity  observes  the 
absence  of  a  binding  for  a  given  uid,  and  another  activity  adds  a  binding  for  the  uid  before  the 
first  activity  completes,  the  first  activity  may  then  observe  the  state  of  the  map  both  before  and 
after  the  second  activity,  thus  violating  serializability. 

Note  that  insert,  delete,  and  lookup  all  call  lind_status  each  time  they  test  whether  the 
appropriate  locks  can  be  acquired  They  cannot  use  the  same  status  object  each  time,  since 
it  might  have  been  removed  from  the  table  by  another  activity's  call  of  cleanup.  The  mutual 
exclusion  enforced  by  the  seize  statement,  however,  ensures  that  a  status  object  returned  by 
find_status  will  remain  in  the  table  at  least  until  the  calling  operation  releases  the  mutex. 


A. 2  Explicit  Implementation  of  the  Map  Type 

In  this  section  we  present  an  implementation  of  the  map  type  using  an  explicit  structure.  The 
implementation  appears  in  Figure  A-5.  It  uses  two  types,  versions  and  set.  whose 
specifications  appear  in  Figures  A-3  and  A-4,  respectively. 

This  implementation  of  map  can  be  viewed  as  an  optimized  implementation  of  the  state 
machine  LOCK  discussed  in  Chapter  5.  suitably  extended  to  allow  activities  to  be  nested  The 
implementation  does  not  store  the  entire  sequence  of  operations  executed  by  each  activity, 
however,  instead,  it  keeps  track  of  a  summary  that  is  sufficient  to  update  the  committed  state 
when  the  activity  commits  and  to  synchronize  with  other  activities. 

Recall  from  the  previous  section  that  we  can  classify  Inseri  and  deieie  operations  that 
terminate  normally  as  writers,  and  all  other  operations  as  readers.  Operations  involving 
different  uids  commute,  as  do  readers  involving  the  same  uid:  a  writer  does  not  commute  with 
any  other  operation  involving  the  same  uid  This  implementation  synchronizes  operations  by 
using  read/write  locks  on  individual  uids  An  operation  can  acquire  a  read  lock  on  behalf  of 
an  activity  as  long  as  no  concurrent  activity  holds  a  write  lock  on  the  same  md:  in  other  words, 
as  long  as  only  ancestors  of  the  requesting  activity  hold  write  locks  An  operation  can  acquire 
a  write  lock  on  behalf  of  an  activity  as  long  as  no  concurrent  activity  holds  a  read  or  write  lock 
on  the  same  uid:  on  other  words,  as  long  as  no  non  ancestors  of  the  requesting  activity  hold 
locks  of  any  kind  When  an  activity  commits,  its  locks  are  transferred  to  its  parent:  when  an 
activity  aborts,  its  focks  are  discarded. 


The  representation  of  a  map  is  enclosed  in  a  mutex  object,  and  consists  of  three  pieces: 
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data  type  vcrsionslt  type]  is  ctcnic.  can_tead.  can_wrilc  read_lock.  wiiie_lock. 

read,  write,  busy,  commit,  abort 

A  versionsfl]  object  is  a  stack  of  versions  each  with  an  associated  set  of  readers  and 
%  writers  The  usual  read/wnte  locking  discipline  for  nested  activities  is  observed:  any 
%  number  of  concurrent  readers,  and  at  most  one  writer  (with  no  concurrent  readers). 

create  =  proc  (x  I)  returns  (versions(l]) 

%  Returns  a  new  object  with  base  state  x. 

can_read  =  proc  (v:  version[t].  a  aid)  returns  (bool) 

%  Returns  true  il  and  only  if  every  writer  of  v  is  an  ancestor  of  a. 

can_write  =  proc  (v;  versionftj,  a  aid)  returns  (bool) 

%  Returns  true  if  and  only  if  every  reader  and  writer  of  v  is  an  ancestor  of  a. 

read  =  proc  (v  version]!],  a:  aid)  returns  (t)  signals  (conflict) 

%  If  a  can  read  v,  returns  the  most  recent  version  of  v;  otherwise  signals  conihci.  Does  not 
%  make  a  a  reader  of  v  (the  operation  reaajock  must  be  used  explicitly  to  set  a  read  lock). 

write  =  proc  (v:  version[i].  x;  t,  a  aid)  signals  (conflict) 

%  If  a  can  write  v,  removes  any  version  of  v  associated  with  a  and  pushes  x  on  v  on  behalf 
%  of  a,  otherwise  signals  con/het.  If  no  conflict,  also  makes  a  a  writer  of  v. 

read.lock  =  proc  (v:  version]!],  a  aid)  signals  (conflict) 

%  If  every  writer  of  v  is  an  ancestor  of  a  then  makes  a  a  reader  of  v;  otherwise  signals  conflict. 

writejock  =  proc  (v:  version]!],  a:  aid)  signals  (conflict) 

%  If  every  reader  and  writer  of  v  is  an  ancestor  of  a  then  makes  a 
%  a  writer  of  v;  otherwise  signals  conflict. 

busy  =  proc  (v;  version]!])  returns  (bool) 

%  Returns  false  if  and  only  if  there  are  no  readers  or  writers  of  v, 

commit  =  proc  (v:  version]!],  a:  aid) 

%  If  a  is  a  reader  (resp.  write-)  of  v,  makes  a’s  parent  (if  any)  a  reader  (resp.  writer)  of  v. 

%  and  removes  a  as  a  reader  (resp.  writer)  of  v.  If  a  version  was  pushed  on  v  on  behalf  of 
%  a,  replaces  version  associated  with  a  s  parent  (if  any)  with  that  associated  with  a. 

abort  a  proc  (v;  version]!],  a:  aid) 

%  Releases  locks  held  by  a  on  v  and  discards  any  versions  of  v  written  by  a. 

Figure  A-3:  informal  specification  of  the  data  type  versions. 
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data  type  set(t  type]  is  create,  insert,  delete,  member,  empty,  append 

create  =  proc  {)  returns  (set[t]) 

%  Returns  a  new,  empty  set. 

insert  =  proc  (s:  set.  x:  t) 

%  Inserts  x  In  s. 

delete  =  proc  (s:  set.  x:  t) 

%  Removes  x  from  s. 

member  =  proc  (s:  set,  x;  t)  returns  (bool) 

%  Returns  true  if  and  only  if  x  is  in  s. 

empty  =  proc  (s:  set)  returns  (bool) 

%  Returns  true  if  and  only  if  s  is  empty. 

append  =  proc  (to.  from:  set) 

%  Inserts  all  elements  in  from  into  to. 

Figure  A-4:  Informal  specification  of  the  datatype  set. 

Items,  which  contains  versions  and  locks  for  uids;  logs,  which  records  for  each  active  aclivity 
a  summary  consisting  of  the  uids  for  which  it  has  executed  operations;  and  pending,  which 
contains  an  activity  queue  for  uids  Items  contains  versions  and  locks  only  for  those  uids  that 
are  bound  in  the  map  or  that  have  been  used  by  an  active  activity.  Pending  contains  queues 
only  for  those  uids  with  pending  operations;  queues  are  created  when  needed,  and  removed 
as  soon  as  all  activities  that  used  them  either  commit  to  the  top  level  or  abort,  items  and 
pending  use  the  type  table,  also  used  in  the  implicit  implementation  of  map  presented  in  the 
previous  section.  The  mutex  object  is  used  to  prevent  interference  among  concurrently 
executing  operations. 

The  implementation  of  insert  works  as  follows:  First,  it  finds  the  summary  for  the  invoking 
activity,  adds  the  uid  to  the  summary,  and  registers  the  activity  and  the  map.  Then,  it  finds  the 
versions  for  the  uid,  and  attempts  to  read  the  most  recent  version.  If  there  is  a  conflict,  the 
operation  blocks  on  the  queue  associated  with  the  uid,  and  tries  again  when  a  conflicting 
activity  becomes  visible  or  aborts.  If  there  is  no  conflict,  the  operation  tests  the  tag  of  the 
version.  If  the  tag  is  "present,"  the  operation  acquires  a  read  lock  on  the  version  and  signals 
duplicate.  If  the  tag  is  "absent,"  the  operation  writes  a  new  version  with  tag  "present"  and 
value  V,  and  returns;  a  write  lock  is  acquired  in  writing  the  new  version,  unless  there  is  a 
conflict,  in  which  case  the  operation  blocks  and  tries  again  later. 

The  implementations  of  delete  and  lookup  are  similar  to  that  of  insert.  They  differ  largely  in 
the  conditions  under  which  they  acquire  particular  types  of  locks. 

The  commit  routine  begins  by  finding  the  summary  for  the  committing  activity.  For  each  uid 
touched  by  the  activity,  it  finds  the  versions  for  the  uid  and  transfers  the  activity's  locks  and 
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Figure  A-5:  Explicit  implementation  of  the  data  type  map 

map  =  cluster[vtyp€  type]  is  create,  insert,  delete,  lookup 

aq  =  action_queue 

status  =  oneot[prescnt  vtype, 
absent:  null] 

tentative  =  versions[status] 

data  =  table[tentative]  %  versions  for  each  uid. 

queues  =  tablefaq]  %  queues  for  pending  operations  on  each  uid. 

summary  =  set[uid]  %  uids  touched  by  an  activity. 

components  =  struct[items:  data, 

logs:  !og[summary], 
pending  queues] 

rep  =  mutex[components] 

%  rep  invariant: 

%  if  there  exists  a  such  that  u  C  rep.value.logs[a],  then  u  is  mapped  by  rep  value.iteire; 
%  if  there  is  a  blocked  operation  involving  u,  then  u  is  mapped  by  rep  value.pending; 

%  a  is  a  reader  or  writer  of  rep  value  items(u]  if  and  only  if  u  f  rep  value  logsfa]; 

%  if  u  is  mapped  by  rep. value.pending  then  u  is  mapped  by  rep.value.items. 

create  s  proc  ()  returns  (evt) 

return(repScreate(components$(itcms:  data$create(), 

logs  log(summary]$create(), 
pending;  QueuesScreateO})) 


end  create 
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Figure  A-5  (continued) 


%  external  spec  insert  =  proc  (m:  cvt  u  uid  v  vtype)  signals  (duplicate) 
insert  =  proc  (a  aid.  m  cvt,  u:  uid.  v  vtype)  signals  (duplicate) 

seize  m  do 

s;  summary  ;  =  lind_log(m  value  logs,  a) 
summary$inserl(s.  u) 
register(a,  m) 

t:  tentative  ;  =  lindjtem(m  value  items,  u) 
while  true  do 

tagease  tentativeSread(t,  a) 

tag  present:  tenlalive$read_lock(t.  a) 
signal  duplicate 

tag  absent:  tentative$write(t,  statu3Smake_present(v),  a) 

return 

end 

except  when  conflict:  q:  aq  :  =  find_queue(m  value  pending,  u) 

block  a  on  q 
continue 


end 

end 

end 

end  insert 


%  external  spec:  delete  =  proc  (m:  cvt.  u  uid)  signals  (notjound) 
delete  =  b[proc]  (a  aid,  m.  cvt,  u:  uid)  signals  (notjound) 
seize  m  do 

s:  Summary  :  =  )ind_log(m. value. logs,  a) 
summarySinsert(s,  u) 
register(a,  m) 

t;  tentative :  =  (indjtem(m. value. items,  u) 
while  true  do 

tagease  tentative$read(t.  a) 

tag  present  tentalive$write{f.  stalus$make_8bsent(nil),  a) 
return 

tag  absent:  tentative$read_lock(t,  a) 
signal  notjound 

end 

except  when  conflict:  q:  aq  :  =  lind_queue(m  value. pending,  u) 

block  a  on  q 
continue 


end 

end 

end 

end  delete 


I 


f 
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Figure  A-5;  (continued) 


%  external  spec:  lookup  =  proc  (m;  cvt  u;  uid)  returns  (vtype)  signats  (notjound) 
lookup  =  proc  (a:  aid,  tn.  cvt,  u:  uid)  returns  (vtype)  signals  (notjound) 
seize  m  do 

s;  Summary  :  =  tindJog(m.value.logs,  a) 
summary$insert(s,  u) 
register(a.  m) 

t:  tentative  =  lindjtem(m.value.items,  u) 
while  true  do 

teniative$read_lock(t,  a) 

except  when  conflict;  q:  aq  .  =  find_queue(m  value. pending,  u) 
block  a  on  q 
continue 


end 

tagcase  tentative$read(l.  a) 

tag  present  (v:  vtype):  return(v) 
tag  absent:  signal  notjound 
end 

end 

end 

end  lookup 


find  Jog  =  proc  (logs:  log(summary),  a:  aid)  returns  (summary) 
return(iogs[a]) 

except  when  notjound.  s:  sumrrtary :  s  summary$cre8te() 
logs(a] ;  s  s 
return(s) 

end 

end  find  Jog 


findjtem  =  proc  (items:  date,  u:  uid)  returns  (tentative) 
t:  tentative : »  data$iookup(items,  u) 

except  when  notjound:  s:  status :  s  status$make_absent(nll) 
t :  -  tentative$create(s) 
data$insert(items,  u,  t) 

end 

return(t) 
end  firxl.item 
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Figure  A-5:  (continued) 

find_queue  =  proc  (pending:  queues,  u:  uid)  returns  (aq) 
q:  aq  :  =  queues$lookup(pending,  u) 

except  when  not_found:  q  :  =  aq$creale() 

queucs$insert(pending.  u,  q) 

end 

relurn(q) 
end  find_queue 

commit  =  proc  (a:  aid.  m:  rep)  signals  (failure(string) 
seize  m  do 

mv:  components  :  =  m.value 
as:  Summary  :  =  mv.logs[a] 

except  when  notjound:  return  end 
(og[summary]$delefe(mv.logs,  a) 
is_lop:  boci :  =  aid$top(a) 
tor  u:  uid  in  summary$elements(as)  do 
t:  tentative  :  =  find _item(mv. items,  u) 
tentative$commit(l,  a) 
q:  aq  :  =  queues$lookup(mv. pending,  u) 

except  when  not_found:  if  is_top  cand  “tentative$busy(t) 

cand  status$is_absent(lentalive$read{t,  a)) 
then  data$delete(mv.items,  u) 
end 

continue 

end 

aq$notlfy(q,  a) 

if  is.top  cand  aq$empty(q) 

then  queues$delete(mv.pending,  u) 

if  ~tentative$busy(t)  cand  status$is_absent(tentative$read(t,  a)) 
then  data$delete(mv.items,  u) 
end 

end 

end 

ps:  Summary :  =  findJog(mv.logs.  aid$parenf(a)) 
except  when  top.  return 
end 

summary$append(ps,  as) 

end 

end  commit 
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Figure  A-S:  (continued) 


abort  =  proc  (a  aid.  m:  rep)  signals  (failure(string) 
seize  m  do 

mv:  components  :  =  m  value 
as;  summary  :  =  mv.logs[a] 

except  when  notjound:  return  end 
loglsummary]$c)elelo(mv.logs.  a) 
for  u:  uid  in  summarySolements(as)  do 
t:  tentative  ;  =  lind_ilem(mv. items,  u) 
tentative$abort(t,  a) 

q:  aq  :  =  queuesSlookup(mv.pending,  u) 

except  when  notjound:  if  ~tentative$busy(t) 

cand  status$is_absent(tentativeSread(t,  a)) 
then  data$delete(mv. items,  u) 

end 

continue 


end 
aq$wake(q) 
if  aq$empty(q) 

then  queues$delete(mv.pendlng,  u) 

if  -tentativeSbusy(t)  cand  status$is_absent(tentative$read(t,  a)) 
then  data$delete(mv.items,  u) 

end 

end 

end 

end 

end  abort 


end  map 


version  (if  any)  to  its  parent  It  then  unblocks  pending  operations  on  the  uid  that  were  invoked 
by  activities  to  which  the  committing  activity  is  now  visible.  Finally,  if  the  versions  or  the 
queue  for  a  uid  are  no  longer  needed,  they  are  deleted  from  the  representation  of  the  map. 
After  processing  each  uid.  the  commit  routine  adds  the  summary  information  for  the  activity 
to  that  for  its  parent. 

The  abort  routine  is  similar:  For  each  uid  touched  by  the  activity,  it  releases  the  activity  s 
locks  and  discards  its  versions,  unblocks  all  pending  operations  for  the  same  uid,  and  then 
deletes  versions  and  queues  that  are  no  longer  needed. 

The  process  scheduling  in  this  implementation  is  safe  in  the  sense  that  all  asleep  pending 
operations  that  can  proceed  will  be  changed  to  waiting,  and  eventually  unblocked,  when  an 
activity  completes.  However,  some  pending  operations  that  cannot  proceed  might  also  be 
unblocked.  For  example,  suppose  that  an  activity  invokes  the  insert  operation  for  a  uid.  and 
the  operation  is  farced  to  block  because  several  other  activities  h.ive  read  locks  on  the  uid. 
When  one  of  the  readers  becomes  visible  to  the  blocked  activity,  the  pending  operation  will  be 
unblocked.  However,  it  can  not  yet  proceed,  since  there  are  still  conflicting  readers. 
Similarly,  if  several  activities  are  blocked  waiting  to  get  a  write  lock  on  a  uid,  they  will  all  be 
unblocked  at  the  same  time,  but  only  one  of  them  will  obtain  the  lock  and  proceed. 

The  commit  and  abort  routines  delete  the  versions  for  a  uid  only  if  no  processes  are  blocked 
on  the  uid’s  queue.  This  permits  the  implementations  of  insert,  delete,  and  lookup  to  find  the 
versions  for  a  uid  only  once,  before  entering  the  loop;  if  one  of  these  operations  blocks,  the 
uid  will  remain  bound  to  the  same  versions  object  at  least  until  the  operation  unblocks. 

A. 3  Explicit  Implementation  of  the  Bank_account  Type 

In  this  section  we  present  an  explicit  implementation  of  the  bank_account  type.  The  serial 
specification  of  a  bank  account  object  was  given  in  Figure  5-2;  the  corresponding  informal 
specification  of  the  bank  account  type  appears  in  Figure  A  6.  (The  signal  neg_arg  appears  in 
the  informal  specification  and  not  in  the  original  serial  specification  because  the  arguments  to 
the  deposit  and  withdraw  operations  in  the  informal  specification  are  integers  rather  than 
natural  numbers.) 

The  implementation  appears  in  Figure  A-8.  It  permits  significantly  more  concurrency  than 
would  be  permitted  by  a  locking  implementation:  for  example,  it  permits  activities  to  withdraw 
money  concurrently  from  an  account  as  long  as  the  account  contains  sufficient  money  to 
cover  all  the  withdrawals.  (Cf.  Section  5.4.2.)  The  implementations  of  the  deposit  and 
withdraw  operations  are  similar  to  the  implementations  of  eng  and  deq  in  the  semiqueue 
implementation  presented  in  Section  7.2.  Deposits  are  handled  using  intentions  lists,  while 


data  type  bank_account  is  create,  deposit,  withdraw,  balance 

%  A  bank  account  always  has  a  non-negative  balance  The  type  Is  dynamic  atomic. 

create  =  proc()  returns  (bank_account) 

%  Returns  a  new  bank  account  with  a  batance  of  0. 

deposit  =  proc  (b:  bank  account  amt  int)  signals  (neg_arg) 

%  Adds  amt  to  b  it  amt  >  0:  otherwise  signals  negjarg. 

withdraw  =  proc  (b.  bank_account.  amt  int)  signals  (msufficientjunds.  neg_arg) 

%  If  amt  <  0  then  signals  ncg_arg:  otherwise  if  amt  >  b  then  signals  insutticientjunds', 

%  otherwise  subtracts  amt  from  ft. 

balance  =  proc  (b:  bank_account)  returns  (int) 

%  Returns  the  current  balance  in  ft. 

Figure  A-6:  Informal  specification  of  the  data  type  bank_account. 

withdrawals  that  terminate  normally  are  handled  using  undo  logs.  Withdrawals  that  signal 
and  balance  operations  are  handled  separately  Not  all  concurrency  permitted  by  on  line 
dynamic  atomicity  is  permitted  by  the  implementation;  lor  example,  withdrawals  that  signal 
cannot  be  executed  concurrently  with  withdrawals  that  succeed.  This  additional  concurrency 
could  be  permitted  at  the  expense  of  a  more  complicated  and  less  efficient  implementation. 

The  implementation  uses  the  data  type  crowd’,  an  informal  specification  of  crowds  appears  in 
Figure  A-7.  The  representation  of  a  bank  account  is  enclosed  in  a  mutex  object,  and  consists 
of  five  pieces:  committed,  which  represents  the  money  known  to  be  in  the  account  (it  has 
been  deposited  by  activities  that  have  committed  to  the  top  level,  and  it  has  not  yet  been 
withdrawn);  chartges,  which  is  a  collection  of  summary  information  about  the  operations 
executed  by  active  activities:  reads,  which  records  the  active  activities  that  have  read  the 
account  (i.e..  executed  withdraw  operations  that  signalled  or  executed  balance  operations); 
writes,  which  records  the  active  activities  that  have  written  the  account  (i.e.,  executed 
withdraw  operations  that  succeeded  or  executed  deposit  operations);  and  pending,  which  is 
used  for  blocking  all  pending  operations  on  the  account. 

The  summary  for  an  activity  consists  of  two  parts;  credit,  which  represents  the  money 
deposited  by  the  activity  (or  its  committed  descendants)  and  not  subsequently  withdrawn;  and 
debit,  which  represents  the  money  withdrawn  by  the  activity  (or  its  committed  descendants), 
and  contains  sufficient  information  to  be  able  to  "undo"  the  withdraw  operations  if  the  activity 
aborts. 

Operations  that  read  the  account  exclude  operations  that  write  it,  and  vice  versa,  but  readers 
can  run  concurrently  with  each  other,  as  can  writers.  The  only  restriction  is  that  a  withdrawal 
operation  can  be  executed  only  when  the  account  is  guaranteed  to  contain  sufficient  funds, 
regardless  of  withdrawals  executed  by  concurrent  activities. 
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data  type  crowd  is  create,  add.  conllicts,  empty,  commit,  abort 

%  A  crowd  IS  a  set  of  activity  ids. 

create  =  proc  ()  returns  (crowd) 

%  Returns  a  new.  empty  crowd. 

add  =  proc  (c;  crowd,  a:  aid) 

%  Adds  a  to  c. 

contlicts  =  proc  (c:  crowd,  a:  aid)  returns  (bool) 

%  Returns  true  if  and  only  if  a  non-ancestor  of  a  is  a  member  of  c. 

empty  =  proc  (c:  crowd)  returns  (boot) 

%  Returns  true  if  and  only  if  c  is  empty. 

commit  =  proc  (c:  crowd,  a;  aid) 

%  If  a  IS  a  member  of  c,  removes  a  from  c  and  adds  a's  parent  (if  any)  to  c. 

abort  =  proc  (c:  crowd,  a:  aid) 

%  Removes  a  from  c. 


Figure  A-7:  Informal  specification  of  the  data  type  crowd. 

The  internal  procedure  llndJower_bound  is  used  to  obtain  a  lower  bound  on  the  amount  of 
money  available  to  an  activity.  It  adds  the  balances  in  the  intentions  list  for  each  ancestor  of 
the  activity  to  the  committed  balance;  since  money  required  to  cover  withdrawals  executed  by 
other  activities  has  been  removed  from  the  intentions  lists,  the  amount  computed  by 
findJower_bound  is  available  to  cover  a  withdrawal  by  the  specified  activity.  The  value 
returned  by  findJower_bound  equals  the  activity’s  view  when  there  are  no  concurrent  writers 

The  implementation  of  deposit  works  as  follows:  First  it  checks  for  conflicting  read 
operations  If  there  is  a  conflict,  it  blocks  and  tries  again  when  one  of  the  conflicting  activities 
has  completed.  Otherwise,  the  invoking  activity  is  added  to  the  set  of  writers,  the  deposited 
amount  is  added  to  the  activity  s  intentions  list  (using  the  internal  procedure  credit),  the 
activity  and  the  object  are  registered,  and  the  operation  returns  The  money  deposited  by  an 
activity  will  only  become  visible  to  the  activity's  siblings  when  the  activity  commits:  if  the 
activity  aborts  the  record  of  the  deposit  will  be  discarded. 

The  implementation  of  withdraw  is  more  complex.  First,  it  uses  lindJowei_bound  to  compute 
a  lower  bound  on  the  money  available  to  the  invoking  activity  There  are  then  three  cases.  If 
the  amount  to  be  withdrawn  is  greater  than  the  lower  bound,  and  there  are  no  concurrent 
writers,  then  the  lower  bound  equals  the  activity's  view  and  the  account  has  insufficient  funds 
In  this  case  the  operations  records  the  activity  as  a  reader,  registers  the  activity  and  the 
object,  and  signals  insutticienljunds.  If  the  amount  to  be  withdrawn  is  less  than  the  lower 
bound,  then  the  account  can  cover  the  withdrawal:  If  there  are  no  concurrent  readers  then 
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Figure  A -8:  Explicit  implementation  of  the  data  type  bank_account. 
bank_account  =  cluster  is  create,  deposit,  withdraw,  balance 

source  =  oneo([commltted;  null, 
active:  aid] 

undo  =  struct[debit:  int, 

taken_trom:  source] 

udiist  =  arrayfundo] 

summary  =  record[credit.  int, 
debit:  udiist] 

aq  =  action_queue 

components  =  record[committed:  int, 

changes:  logfsummary], 
reads,  writes:  crowd, 
pending:  aq] 

rep  s  mutex[components] 

%  rep  invariant: 

%  rep.value.committed  >  0;  for  each  activity  a,  and  for  each  undo  record  u  in 
%  rep. value.logs(a]. debit,  either  tag(o.taken_from)  =  committed,  or  value(u.taken_from) 

%  is  mapped  by  rep. value. changes;  if  a  €  rep.value.writes,  then  a  is  mapped 

%  by  rep  value.changes 

create  =  proc  ()  returns  (cvt) 

return(rep$create(componentsS{committed:  0, 

changes:  Iog[summary]$create0. 
reads:  crovrdScreateO. 
writes:  crowdScreateO. 
perKting:  aq$create()})) 


end  create 


Figure  A-8  (continued) 


%  external  spec:  deposit  =  proc  (b  cvt  amt  int)  signals  (neg_arg) 
deposit  =  proc(a  aid  b  cvt,  amt  int)  signals  (neg.arg) 
it  amt  <  0  then  signal  neg^arg  end 
seize  b  do 

while  true  do 

if  crowd$confiicts{b  value  reads,  a) 
then  block  a  on  b  value  pending 
continue 

else  crowd$add(b  value. writes,  a) 
credit(b  value  changes,  a,  amt) 
register(a,  b) 
return 

end 

end 

end 

end  deposit 

%  external  spec  withdraw  =  proc  (b  cvt.  amt  int)  signals  (insufficientjunds,  neg_arg) 
withdraw  =  proc  (a  aid.  b:  cvt,  amt  int)  signals  (msulficientjunds,  neg_arg) 
if  amt  <  0  then  signal  neg.arg  end 
seize  b  do 

bv  components  =  b  value 

while  true  do 

lb  int :  =  findJower_bound(bv,  a) 
if  amt  >  lb  cand  ~crowd$conflicts(bv  writes,  a) 
then  crowd$add(bv  reads,  a) 
register(a,  b) 
signal  insuflicient_funds 

elseif  amt  <  lb  cand  ~crowd$conflicts(bv. reads,  a) 
then  crowd$add(bv. writes,  a) 
debit(bv,  a,  amt) 
register(a,  b) 
return 

else  block  a  on  bv. pending 
continue 

end 

end 

end 

end  withdraw 
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Figure  A-8  (continued) 


%  external  spec  balance  =  proc  (b  cvt)  returns  (int) 
balance  =  proc  (a  aid,  b  cvt)  returns  (int) 
seize  b  do 

while  true  do 

if  crowd$confiicis(b  value  writes,  a) 
then  block  a  on  b  value  pending 
continue 

else  crowd$add(b  value  reads,  a) 
register{a,  b) 

return(lind_lower_bound(b.value,  a)) 

end 

end 

end 

end  balance 


%  Returns  a  lower  bound  on  the  aniount  ol  money  available  to  a,  the  value  returned  equals 
%  a  s  view  if  no  concurrent  activity  has  deposited  or  withdrawn  money. 
find_lower_bound  =  proc  (c:  components,  a:  aid)  returns  (int) 
lb:  int :  =  c. committed 

for  anc;  aid,  s:  summary  in  log[summary]$ancestors(c, changes,  a)  do 
lb ;  =  lb  +  s. credit 

end 

return(lb) 

end  find_lower_  bound 

findjog  =  proc  (logs:  log[summary),  a:  aid)  returns  (summary) 
return(logs[a]) 

except  when  not_found:  s:  summary  :  =  summary${credit;  0,  debit:  udlist$new()) 
logs[a] ;  s  s 
return(s) 

end 

end  find.log 


- ■ 
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Figure  A-8  (continued) 

commit  =  proc(a  aid,  b;  rep)  signals  {lailurc(string)) 
seize  b  do 

bv  components  =  b  value 
crowd$commit(bv  reads,  a) 
crowdScommil(bv  writes,  a) 
aq$notify(bv  pending,  a) 
as.  summary  :  -  bv.changes[a] 

except  when  not_(ound  return  end 
log[summary]$delete{bv. changes,  a) 
ps  summary  =  finclJog(bv.changcs  aid$pafent(a)) 

except  when  top  bv  coirimiticd  =  bv  committed  +  as  credit 
return 

end 

ps  credit  =  ps  credit  +  as. credit 
merge_debits(aidSparent(a).  ps  debit,  as  debit) 

end 

end  commit 

abort  =  proc  (a  aid,  b  rep)  signals  {failure(string)) 
seize  b  do 

bv  components  :  =  b, value 
crowd$abori(bv  reads,  a) 
crowd$abort(bv. writes,  a) 
aq$wake(bv  pending) 
as:  summary  =  bv,changes[a] 

except  when  not_found  return  end 
log  [summary]$deieto(bv. changes,  a) 
for  u:  undo  in  udlist$eiements(as, debit)  do 
tagcase  u,taken_from 

tag  committed,  bv. committed  :  =  bv. committed  +  u. debit 
tag  active(anceslor;  aid)  anc_s.  summary  :  =  find.log(bv, changes,  ancestor) 
anc.s. credit :  =  anc_s  credit  +  u. debit 

end 

end 

end 

end  abort 

credit  =  proc  (effects:  log[summary],  a:  aid,  amt:  int) 
s:  summary  ;  =  find_log{effects,  a) 
s. credit :  =  s. credit  +  amt 
end  credit 


I 
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Figure  A-8:  (continued) 

debit  =  proc  (c  components,  a  aid.  amt:  int) 
s  summary  =  find_log(c. Changes,  a) 

tor  anc  aid  anc_s  summary  in  lo(j(summaryj$leaf?root(c  changes,  a)  do 
it  anc_s  credit  >  0  then 
if  anc  ~  =  a  then 

if  amt  >  anc_s  credit 
then 

udiist$addh(s.debit, 

undo${debit:  anc_s  credit,  iaken_from:  source$make_active{anc))) 

else 

udiist$addh(s.debit, 

undo${dobit:  amt,  takenjrom  source$make_active(anc))) 

end 

end 

it  amt  >  anc_s  credit 

then  amt  =  amt  -  anc_s  credit 
anc.s  credit :  =  0 

else  anc.s  credit :  =  anc.s.credit  •  amt 
amt  :  =  0 

end 

end 

if  amt  =  0  then  return  end 
end 

if  amt  >0then 

c  committed  .  =  c  committed  ■  amt 

udlist$addh(s. debit,  undo${debit:  amt,  takenjrom:  source$make_committed  nil}) 
end 

end  debit 

%  appends  undos  in  from  onto  to.  ignoring  undos  with  takenjrom  =  parent, 
merge.debits  =  proc  (parent:  aid,  to:  udiist.  from:  udiist) 
for  u  undo  in  udlistSelements(from)  do 
tagease  u. takenjrom 
tag  committed: 

tag  activc(ancestor:  aid):  if  ancestor  =  parent  then  continue  end 
end 

udiist$addh(to,  u) 

end 

end  merge.debits 


end  bank.account 


tlje  activity  is  recorded  as  a  writer,  the  specified  amoant  is  removed  from  the  committed 
balance  and  the  intentions  lists  of  the  activity's  ancestors,  and  recorded  m  the  undo  log 
(using  the  internal  procedure  debit),  with  sufficient  information  to  be  able  to  put  the  money 
back  in  the  intentions  lists  from  which  it  was  removed;  the  activity  and  the  object  are 
registered;  and  the  operation  returns.  In  all  other  cases  the  operation  blocks  and  tries  again 
later. 

Debit  searches  the  intentions  lists  for  the  activity  and  its  ancestors,  removing  money  from  the 
intentions  lists  and  adding  appropriate  undo  records  to  the  activity's  undo  log  so  that  the 
money  can  be  returned  to  the  proper  list  if  the  activity  aborts.  (It  searches  from  the  activity 
toward  the  root  to  try  to  minimize  the  impact  on  concurrent  activities.)  If  the  activity  withdraws 
money  that  it  (or  one  of  its  committed  descendants)  had  deposited,  the  operations  cancel  (at 
least  in  part),  and  no  record  of  the  canceling  pari  is  kept.  If  the  activity  and  its  ancestors  have 
not  deposited  sufficient  money  to  cover  the  withdrawal,  money  is  removed  from  the 
committed  balance  instead.  Debit  assumes  that  the  lower  bound  on  the  funds  available  to  the 
activity  is  greater  than  the  amount  to  be  withdrawn;  otherwise  the  committed  balance  would 
become  negative  violating  the  representation  invariant.  It  is  easy  to  see  that  the  call  to  debit 
in  the  implementation  of  withdraw  satisfies  this  precondition. 

The  implementation  of  baiarice  is  simple:  If  there  are  no  conflicting  writers,  the  invoking 
activity  is  recorded  as  a  reader  and  registered  with  the  object,  and  the  activity's  view  is 
returned  Otherwise  the  operation  blocks  and  tries  again  later. 

The  implementation  of  commit  follows  the  pattern  of  the  semiqueue  implementation 
presented  earlier.  First,  it  commits  the  activity  in  the  crowds  of  readers  and  writers,  and 
unblocks  pending  operations  that  might  now  be  able  to  proceed.  Then,  it  finds  the  summaries 
for  the  activity  and  its  parent,  deletes  the  summary  for  the  activity,  and  merges  its  intentions 
lists  and  undo  logs  into  its  parent's  (Undos  that  cancel  with  the  parent's  deposits  are 
discarded.)  If  the  activity  is  a  top  level  activity,  the  deposits  are  added  into  the  committed 
balance,  and  the  entire  summary  is  discarded. 

The  abort  routine  is  also  similar  to  the  abort  routine  in  the  semiqueue  implementation.  It 
aborts  the  activity  in  the  crowds,  and  then  unblocks  all  pending  invocations.  Next,  it  retrieves 
the  summary  for  the  activity,  deletes  it,  and  uses  the  information  in  the  undo  list  to  return  all 
withdrawn  money  to  the  intentions  list  from  which  it  was  taken. 

Withdrawals  that  signal  could  be  run  concurrently  with  withdrawals  that  succeed  and  with 
deposits  if  sufficient  information  were  maintained  to  determine  an  upper  bound  on  the  money 
available  to  an  activity.  Reuter  [Reuter  82)  has  explored  an  implementation  of  a  similar  type 
(to  be  used  for  reserving  seats  on  flights  in  an  airline  reservation  system)  that  exploits  this 
idea.  However,  the  implementation  is  quite  subtle,  and  probably  inefficient. 
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A. 4  Remarks 

The  implementation  of  the  bank_account  type  is  interesting  (or  two  reasons  First,  it  illustrates 
how  a  type  that  permits  more  concurrency  than  can  be  obtained  using  locking  can  be 
implemented  Second,  we  have  been  unable  to  construct  an  implicit  implementation  of  the 
bank_account  type  that  provides  a  comparable  level  of  concurrency:  while  it  is  difficult  to 
argue  that  no  such  implementation  exists,  it  is  clear  that  such  an  implementation  would  be 
quite  complex.  The  problem  is  partly  due  to  the  inability  to  tell  which  changes  to  the 
representation  were  made  by  which  activity  (because  the  representation  cannot  be  organized 
to  group  data  by  aids),  and  partly  due  to  the  asynchronous  processing  of  commits  and  aborts 
by  the  system.  In  contrast  to  the  implicit  approach,  the  explicit  approach  permits  a  reasonably 
systematic  approach  to  building  implementations  like  the  bank_account  implementation  in 
Figure  A-8. 

It  is  also  instructive  to  compare  the  two  implementations  of  the  map  type  First,  the  explicit 
implementation  is  much  more  efficient  in  scheduling  operations  While  the  implicit 
implementation  uses  busy-waiting,  the  explicit  implementation  uses  separate  queues  for  each 
uid  for  which  an  operation  is  blocked,  and  only  unblocks  a  pending  operation  when  an  activity 
that  used  the  uid  of  interest  to  the  operation  becomes  visible  to  the  activity  that  invoked  the 
operation.  A  queue  is  actually  stored  for  a  uid  only  if  an  activity  that  invoked  an  operation  on 
the  uid  was  forced  to  wait  and  is  still  active. 

Second,  the  explicit  implementation  does  not  need  a  "cleanup”  operation  to  keep  the 
representation  from  growing  too  large  Instead,  versions  for  a  uid  can  be  discarded  when  an 
activity  completes,  precisely  at  the  time  that  they  are  no  longer  needed  The  kind  of  periodic 
"garbage  collection"  performed  by  the  cleanup  operation  in  the  implicit  implementation  of 
map  seems  characteristic  of  implicit  implementations. 

Third,  in  the  explicit  implementation  the  programmer  keeps  track  of  the  uids  used  by  an 
activity.  Otherwise,  when  an  activity  completed,  it  would  be  necessary  to  commit  or  abort  the 
activity  on  the  versions  for  all  uids:  unless  the  map  were  quite  small,  this  approach  would  be 
too  inefficient.  In  the  implicit  implementation,  the  system  keeps  track  automatically  of  the 
built  in  atomic  objects  used  by  each  activity,  avoiding  having  to  represent  and  manipulate  this 
information  explicitly. 

Finally,  it  is  instructive  to  compare  the  sizes  of  the  two  implementations.  The  implicit 
implementation  contains  64  lines  of  code,  while  the  explicit  implementation  contains  156  lines 
of  code.  This  additional  complexity  arises  from  several  sources.  First,  the  tagtest  statement 
in  Argus  provides  an  efficient  encoding  of  the  lock  tests  in  the  bodies  of  the  loops  in  the 
insert,  delete,  and  member  routines;  the  explicit  implementation  requires  a  total  of  12  extra 
tines  of  code  for  testing  and  setting  locks.  Second.  31  lines  of  the  explicit  implementation  are 
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devoted  to  managing  queues,  and  could  be  removed  if  busy  waiting  were  used  instead 
Third,  13  lines,  not  counting  those  in  the  completion  operations,  are  devoted  to  keeping  i  jck 
of  the  uids  used  by  each  activity.  Finally,  the  completion  operations  contain  37  lines,  not 
counting  those  needed  to  manage  queues. 
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Appendix  B 

Index  of  Definitions 


This  appendix  contains  an  index  of  the  terms  and  notations  defined  in  Chapters  2  through  5. 


abort  event 

27 

abortecUh) 

28 

acceptable 

36 

accepted  by 

30 

activity 

27 

atomic 

36 

behavior  of  system 

34 

behavioral  specification 

32 

commit  event 

27 

commit  orderih) 

52 

committed(h) 

28 

commute 

64 

completed{h) 

28 

complete  sequence 

29 

completion 

27 

concatenation  ("•") 

28 

defined  in 

30 

deterministic  invocation 

63 

dynamic  atomic  history 

45 

dynamic  atomic  object 

46 

empty  sequence  ("A") 

28 

equivalent 

36 

failure-free  history 

35 

history 

29 

hybrid  atomic  history 

56 

hybrid  atomic  object 

57 

Initiation  event 

55 

invocation  event 

27 

language 

30 

local  atomicity  property 

43 

LOCK 

66 

non-deterministic  invocation 

63 

object 

27 

observation 

28 

on-line  dynamic  atomic 

71 

operation 

32 

opseq{h) 

35 

optimal 

47 

partial  function  {"-♦p") 

20 

partial  invocation 

63 

perform. 

63 

permanent(h) 

38 

precedes{h) 

44 

prefix -closed 

31 

read  only  activity 

54 

read  only  operation 

54 

restriction  operators  {‘T') 

28 

serial{h,  T) 

37 

serial  history 

35 

serial  specification 

31 

serializable 

37 

state  machine 

30 

static  atomic  history 

51 

static  atomic  object 

52 

strong  riynamic  atomic 

70 

termination  event 

27 

timestamp  event 

55 

total  invocation 

63 

undefined  {"-L") 

30 

update  activity 

54 

weaker 

47 

well-formed  sequence 

29,55 
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